15

in this guide https://www.rabbitmq.com/api-guide.html RabbitMQ guys state:

Channels and Concurrency Considerations (Thread Safety)

Channel instances must not be shared between threads. Applications should prefer using a Channel per thread instead of sharing the same Channel across multiple threads. While some operations on channels are safe to invoke concurrently, some are not and will result in incorrect frame interleaving on the wire. Sharing channels between threads will also interfere with * Publisher Confirms.

Thread safety is very important so I tried to be as diligent as possible, but here's the problem:

I have this application that receives messages from Rabbit. When a message is received, it processes it and then acks when it's done. The application can process just 2 items at the same time in a fixed thread pool with 2 threads. The QOS prefetch for Rabbit is set to 2, because I don't want to feed the app with more than it can handle in a time frame.

Now, my consumer's handleDelivery does the following:

Task run = new Task(JSON.parse(message));    
service.execute(new TestWrapperThread(getChannel(),run,envelope.getDeliveryTag()));

At this point, you already figured out that TestWrapperThread does the channel.basicAck(deliveryTag, false); call as last operation.

By my understanding of the documentation, this is incorrect and potentially harmful because channel is not thread safe and this behavior could screw things up. But how I am supposed to do then? I mean, I have a few ideas but they would def make everything more complex and I'd like to figure it out if it's really necessary or not.

Thanks in advance

Community
  • 1
  • 1
Simone Pezzano
  • 197
  • 2
  • 10

1 Answers1

12

I suppose you are using Channel only for your consumer and not for other operations like publish etc..

In your case the only potential problem is here:

channel.basicAck(deliveryTag, false);

because you call this across two thread, btw this operation is safe, if you see the java code:

the class ChannelN.java calls:

public void basicAck(long deliveryTag, boolean multiple)
   throws IOException
{
   transmit(new Basic.Ack(deliveryTag, multiple));
}

see github code for ChannelN.java

the transmit method inside AMQChannel uses:

public void transmit(Method m) throws IOException {
   synchronized (_channelMutex) {
       transmit(new AMQCommand(m));
   }
}

_channelMutex is a protected final Object _channelMutex = new Object();

created with the class. see github code for AMQChannel.java

EDIT

As you can read on the official documentation, "some" operations are thread-safe, now it is not clear which ones. I studied the code, an I think there are not problems to call the ACK across more threads.

Hope it helps.

EDIT2 I add also Nicolas's comment:

Note that consuming (basicConsume) and acking from more than one thread is a common rabbitmq pattern that is already used by the java client.

So you can use it safe.

Gabriele Santomaggio
  • 21,656
  • 4
  • 52
  • 52
  • Only the consumer. So you're substantially confirming it shouldn't be a problem? Do you think the documentation actually meant "be thread safe in promiscuous receive/send situations"? – Simone Pezzano Jun 07 '15 at 17:34
  • Thanks Gas. I think I have a theory on why they substantially say you shouldn't multi-thread a channel, also explicitly mentioning the acknowledgement operation. I think the problem is if you massively use the channel in various threads, in send operations of big amount of data you basically block the channel until they're done. Now if you need to send back acknowledgements as well, they might delay a lot, possibly having your system to trigger "recovery" procedures when it's actually not needed. – Simone Pezzano Jun 07 '15 at 20:04
  • 1
    Note that consuming (basicConsume) and acking from more than one thread is a common rabbitmq pattern that is already used by the java client. – Nicolas Labrot Jun 07 '15 at 20:09
  • @SimonePezzano it is more about `incorrect frame interleaving on the wire.` than blocking. – Nicolas Labrot Jun 07 '15 at 20:12
  • 7
    Thanks everyone for the great help. At this point, all I had to do was trying to figure out what frame interleaving actually is in the RabbitMQ context. And I found it out. Every time you publish a non-empty message, your client sends 3 (or more) frames on the wire: `[method: basic.publish] [content headers] [content body]+` When publishing on the same channel from multiple threads, you may end up with incorrect interleaving, e.g. `[method: basic.publish] [content headers] [method: basic.publish] [content body] [content headers] [content body]` All clear then, thanks! – Simone Pezzano Jun 08 '15 at 07:37