user967710
user967710

Reputation: 2007

Rabbitmq - how to handle channels when not automatically acking messages

I have what I believe is a common use case with RabbitMQ: worker queues - A server gets requests from users and stores them in a queue to handle later. Problem is that some of the task may take up to a minutes, and so I decided to not auto ack:

GetResponse response = channel.basicGet(queueName, false);

I want to ack when the work has finished

channel.basicAck(deliveryTag, false);

From what I know: https://www.rabbitmq.com/confirms.html ("sending a basic.ack on the same channel" - acknowledgement should be made on the same channel that received the message).

So I decided to have a map of messages to channels (In my use case I have a single channel per message). Each time the message's work is done, I ack.

I think this design is very flawed. It forces me to save a state in my server, and forces me to to have a channel per message, instead of maybe reusing channels.

I'm sure this is a widely common use case - what would be : 1. Should I defer to using thread local channels? If so, is it ok to ack messages on a different thread? 2. Is there a better way to handle acking messages than saving this message -> channel map?

Thank you

Upvotes: 0

Views: 351

Answers (1)

Derick Bailey
Derick Bailey

Reputation: 72858

i'm not too terribly familiar with java, but from what i understand having a single channel per thread is correct. i don't think channels are thread safe.

additionally, storing the channel id (or name or whatever it is) and acking the message on that same channel is necessary

i don't personally see anything wrong with the high level overview of what you have provided.

you're right, though, that a "channel per message" is a bad idea. it should be channel per thread, and you can consume multiple messages on the same channel and within the same thread.

just be sure to ack the message on the channel from which it was consumed

Upvotes: 1

Related Questions