How to specify deliver_group?

[raymondsze]

I got this error with following codes:
(node:64650) UnhandledPromiseRejectionWarning: Error: durable requires no queue group

 const opts = consumerOpts();
    opts.queue('me');
    opts.durable('me');
    // opts.deliverTo('me');
    opts.startSequence(1);
    opts.manualAck();
    opts.ackAll();
    opts.maxAckPending(1);
    opts.deliverTo(createInbox());
    const sub = await js.subscribe('a.*', opts);
    (async () => {
      // eslint-disable-next-line no-restricted-syntax
      for await (const m of sub) {
        console.log(sc.decode(m.data));
        m.ack();
      }
    })();

So durable cannot have queue group?

[aricart]

They can, but the consumer must be created with a queue group.
In the case of the magic jetstream subscribe(), you can specify it via the queue(n) option will do it, but the consumer must not exist. If the consumer exists already, you'll get an error from v2.2.0 or better.

If using the JSM functionality, the consumer config exposes deliver_group:

export interface ConsumerConfig {
...
  "deliver_group"?: string;
 ...
}

[aricart]

#446

[Nahasean94]

@aricart , what do you 'mean consumer must not exist'?. I have a similar setup to the one in the question above and getting the same error with natsjs version 2.6.1.
I have a chicken and egg situation. I have a consumer running on kubernetes and horizontally scaled to more than one pod. If I remove the opts.queue('value'), all pods of the same consumer instance are processing the message- in my case, the pods send emails and so the client gets as many emails as there are pod instances. If I specify a queue group name, I get the error above. Is there a configuration am missing here? Code snippet extracted for relevancy:

        const opts = consumerOpts()
                opts.durable(this.queueGroupName + ':' + this.subject.split('.').join('_'))
                opts.manualAck()
                opts.ackExplicit()
                opts.deliverTo(this.queueGroupName + ':' + this.subject)
                opts.queue(this.queueGroupName + ':' + this.subject)
            
                let sub = await this.client.jetstream().subscribe(this.subject,opts)
 

[aricart]

the durable should not exist - it cannot be changed from non queue to queue, you can create it with a queue group, and the other clients can reuse (it will be found) and they will all be part of that queue group.

[aricart]

@Nahasean94 I worry when I see names for durables that have complexity as above that derives from some of the settings. I would instead use some simple name as in service_x and queue group as workers - use the JSM api or the nats-cli to create it , and then use the bind property to attach to it.

Better yet don't do queue groups and instead create a pull consumer and have multiple processes pulling from the same consumer. Pull consumers automatically horizontally scale.

[Nahasean94]

@aricart Do you have an example of your second comment? I am new to Nats and I want to adopt it in my startup, but nats concepts are a little cherry picked in my head. However, I am more interested in this concept "Better yet don't do queue groups and instead create a pull consumer and have multiple processes pulling from the same consumer. Pull consumers automatically horizontally scale."-- My end goal is- have a config that I can scale up/down pods for my notification deployment, without sending multiple emails to my clients because the horizontally scaled pods are all processing the same message. Does this make sense?
Do you write blogs or sth more comprehensive?