Package eu.vstoyanov.natsy.jetstream

Class ConsumerConfigBuilder

  • All Implemented Interfaces:
    
public final class ConsumerConfigBuilder

    Builder for JetStream consumer configuration

    • Constructor Detail

      • ConsumerConfigBuilder

        ConsumerConfigBuilder()

    • Method Detail

      • getDurable

         final String getDurable()

        Durable name for the consumer If null, the consumer will be ephemeral

      • setDurable

         final Unit setDurable(String <set-?>)

        Durable name for the consumer If null, the consumer will be ephemeral

      • getName

         final String getName()

        Name for the consumer, without making it durable

        A named consumer is still ephemeral - the server reaps it once inactiveThreshold passes - but it is addressable and re-attachable in the meantime, where an unnamed one gets a server-generated name nobody can predict. Set durable instead for a consumer that outlives its subscribers.

      • setName

         final Unit setName(String <set-?>)

        Name for the consumer, without making it durable

        A named consumer is still ephemeral - the server reaps it once inactiveThreshold passes - but it is addressable and re-attachable in the meantime, where an unnamed one gets a server-generated name nobody can predict. Set durable instead for a consumer that outlives its subscribers.

      • getAckWait

         final Duration getAckWait()

        How long to wait for acknowledgment before redelivering

      • getMaxDeliver

         final Integer getMaxDeliver()

        Maximum number of delivery attempts (-1 for unlimited)

      • getFilterSubject

         final String getFilterSubject()

        Filter messages by subject

        One subject; use filterSubjects for several. They are two names for one server field, so setting both is rejected rather than resolved by precedence.

      • setFilterSubject

         final Unit setFilterSubject(String <set-?>)

        Filter messages by subject

        One subject; use filterSubjects for several. They are two names for one server field, so setting both is rejected rather than resolved by precedence.

      • getFilterSubjects

         final List<String> getFilterSubjects()

        Filter messages by several subjects

        The plural form of filterSubject; a consumer over orders.created and orders.cancelled without the orders.updated in between.

      • setFilterSubjects

         final Unit setFilterSubjects(List<String> <set-?>)

        Filter messages by several subjects

        The plural form of filterSubject; a consumer over orders.created and orders.cancelled without the orders.updated in between.

      • getRateLimit

         final Long getRateLimit()

        Rate limit in bits per second (-1 for unlimited)

      • setRateLimit

         final Unit setRateLimit(Long <set-?>)

        Rate limit in bits per second (-1 for unlimited)

      • getMaxPullWaiting

         final Integer getMaxPullWaiting()

        Maximum number of pull requests that may wait on the consumer at once

        null - the default - leaves the limit to the server, which allows 512.

      • setMaxPullWaiting

         final Unit setMaxPullWaiting(Integer <set-?>)

        Maximum number of pull requests that may wait on the consumer at once

        null - the default - leaves the limit to the server, which allows 512.

      • getMaxBatch

         final Integer getMaxBatch()

        Largest batch a single pull request may ask this consumer for

        null - the default - leaves the limit to the server, which does not cap batches. Set it only to cap them deliberately: the server answers any larger fetch with a 409 that the client treats as a handled status, so an over-sized fetch quietly returns nothing.

      • setMaxBatch

         final Unit setMaxBatch(Integer <set-?>)

        Largest batch a single pull request may ask this consumer for

        null - the default - leaves the limit to the server, which does not cap batches. Set it only to cap them deliberately: the server answers any larger fetch with a 409 that the client treats as a handled status, so an over-sized fetch quietly returns nothing.

      • getMaxExpires

         final Duration getMaxExpires()

        Longest a pull request against this consumer may wait

        ZERO - the default - leaves the limit to the server. Set it only to cap expiry deliberately: the server answers any longer fetch with a 409 that the client treats as a handled status, so an over-long fetch quietly returns nothing rather than fail.

      • setMaxExpires

         final Unit setMaxExpires(Duration <set-?>)

        Longest a pull request against this consumer may wait

        ZERO - the default - leaves the limit to the server. Set it only to cap expiry deliberately: the server answers any longer fetch with a 409 that the client treats as a handled status, so an over-long fetch quietly returns nothing rather than fail.

      • getDeliverGroup

         final String getDeliverGroup()

        Deliver group for queue semantics (push consumers only)

        A deliver group balances among subscribers of one consumer's deliver subject, so it needs a consumer every collector can share - however the group was asked for. Pass consumerName to JetStreamContext.subscribe, or set durable here. Without one, every collector creates its own ephemeral consumer on its own inbox and receives every message instead of a share of the work.

        This is the same field JetStreamContext.subscribe's queue parameter writes. That spelling is refused at the call when consumerName is missing; this one is refused at collection, once the configuration has been built and both spellings are visible.

      • setDeliverGroup

         final Unit setDeliverGroup(String <set-?>)

        Deliver group for queue semantics (push consumers only)

        A deliver group balances among subscribers of one consumer's deliver subject, so it needs a consumer every collector can share - however the group was asked for. Pass consumerName to JetStreamContext.subscribe, or set durable here. Without one, every collector creates its own ephemeral consumer on its own inbox and receives every message instead of a share of the work.

        This is the same field JetStreamContext.subscribe's queue parameter writes. That spelling is refused at the call when consumerName is missing; this one is refused at collection, once the configuration has been built and both spellings are visible.

      • getFlowControl

         final Boolean getFlowControl()

        Enable flow control for push consumers

        Flow control prevents the server from overwhelming slow consumers. When enabled, the server sends flow control messages that the NATS client automatically handles. Requires idleHeartbeat to be set.

        Note: Only valid for push consumers (requires deliverSubject).

      • setFlowControl

         final Unit setFlowControl(Boolean <set-?>)

        Enable flow control for push consumers

        Flow control prevents the server from overwhelming slow consumers. When enabled, the server sends flow control messages that the NATS client automatically handles. Requires idleHeartbeat to be set.

        Note: Only valid for push consumers (requires deliverSubject).

      • getIdleHeartbeat

         final Duration getIdleHeartbeat()

        Idle heartbeat interval for push consumers

        The server will send heartbeat messages if no data messages are sent within this interval. This allows the consumer to detect connectivity issues.

        When flowControl is enabled, this value determines both the flow control and heartbeat interval. Recommended minimum: 1 second (avoid values like 500ms which cause excessive server load).

      • setIdleHeartbeat

         final Unit setIdleHeartbeat(Duration <set-?>)

        Idle heartbeat interval for push consumers

        The server will send heartbeat messages if no data messages are sent within this interval. This allows the consumer to detect connectivity issues.

        When flowControl is enabled, this value determines both the flow control and heartbeat interval. Recommended minimum: 1 second (avoid values like 500ms which cause excessive server load).

      • getStartSequence

         final Long getStartSequence()

        Start sequence for BY_START_SEQUENCE deliver policy

      • getReplicas

         final Integer getReplicas()

        Number of replicas for the consumer (-1 for stream default)

      • setReplicas

         final Unit setReplicas(Integer <set-?>)

        Number of replicas for the consumer (-1 for stream default)

      • getBackoff

         final List<Duration> getBackoff()

        How long to wait before each redelivery, instead of a fixed ackWait

        The standard poison-message mitigation: listOf(1.seconds, 5.seconds, 30.seconds) retries quickly for a blip and slowly for an outage, and with maxDeliver set it bounds how long a message can keep failing before it is dead-lettered. The list overrides ackWait for as many redeliveries as it has entries, and the last entry applies to every attempt after that (jnats io/nats/client/api/ConsumerConfiguration.java:1407).

      • setBackoff

         final Unit setBackoff(List<Duration> <set-?>)

        How long to wait before each redelivery, instead of a fixed ackWait

        The standard poison-message mitigation: listOf(1.seconds, 5.seconds, 30.seconds) retries quickly for a blip and slowly for an outage, and with maxDeliver set it bounds how long a message can keep failing before it is dead-lettered. The list overrides ackWait for as many redeliveries as it has entries, and the last entry applies to every attempt after that (jnats io/nats/client/api/ConsumerConfiguration.java:1407).

      • getMetadata

         final Map<String, String> getMetadata()

        Free-form key-value pairs stored on the consumer

        For whoever has to work out later which deployment created it. The server keeps its own _nats.* entries alongside these and they are left alone.

      • setMetadata

         final Unit setMetadata(Map<String, String> <set-?>)

        Free-form key-value pairs stored on the consumer

        For whoever has to work out later which deployment created it. The server keeps its own _nats.* entries alongside these and they are left alone.

      • raw

         final Unit raw(Function1<ConsumerConfiguration.Builder, Unit> customize)

        Reach a jnats consumer setting this DSL does not model

        ConsumerConfiguration.Builder carries more than natsy has an opinion about; maxBytes, priorityGroups, priorityPolicy and pauseUntil are all reachable here rather than being unreachable until natsy grows a property for each.

        Applied last, after everything else this block sets, so it can also override those. Blocks accumulate, and they apply wherever natsy patches a consumer it found already there: a raw { } in a consumer { } block, or in ConsumerContext.update, is part of the patch, exactly like an assigned property.

        Binding is not one of those paths. subscribe(consumerName = …) naming a consumer that already exists hands jnats the server's copy and builds nothing, so a block here could only be discarded - and is refused instead, by name, like any other configuration that binding would ignore.

        raw { maxBytes(1024 * 1024) }