I could do that. I'd just have to keep track of which channel each
message came from.
Why is this?
My current app needs to process messages in batches of 4, and it's
getting messages from multiple queues (although I think that might be
unnecessary). Once the messages are batched together into a group of
4, they are put into a BlockingQueue, where another thread processes
the batch and then acks the messages as being done. So, my basic
design is to have Consumers on each queue (each batch of work has only
messages from a single queue) aggregating messages and putting them
into the BlockingQueue once enough have been received.
If I only have one channel that's shared everywhere, I can just give
that channel to the thread that's doing the batch processing and it
can ack the messages on the only channel that there is. If there are
multiple channels, then each message must be acked on the channel that
it was received on, so the message, the dtag, and the channel must all
be kept track of. It's not a difficult thing, but a single shared
channel just seems cleaner somehow.
All this might be obsolete, since I may be able to just use a single
queue for all of these messages. The messages all have the same
structure, and they're all processed by the same program, but they are
messages about different events, so I have them in different queues.
I might change that, since it's starting to look like excessive
complication now that I look at it carefully.