.NET EventingBasicConsumer.Received event handler called from multiple threads

[Nick Lydon]

Our intention is that our messages should be consumed serially, therefore we have 1 consumer per queue. The messages are all identical, and are published to indicate that the consumer should request the next resource from the server.
Recently we had an issue where our Received event handler was called concurrently by 2 different threads. I've attached a screenshot of the logs at this time, which show the timestamp, thread id and message correlation id. At first the handler is called from thread 113, but then switches to 178. Could it be that these "duplicates" are due to the prefetch count of 5?
We also logged an exception around this time, whilst attempting to manually acknowledge a message:
RabbitMQ.Client.Exceptions.AlreadyClosedException: Already closed: The AMQP operation was interrupted: AMQP close-reason, initiated by Library, code=541, text="Unexpected Exception", classId=0, methodId=0, cause=System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) --- End of inner exception stack trace --- at RabbitMQ.Client.Impl.InboundFrame.ReadFrom(NetworkBinaryReader reader) at RabbitMQ.Client.Framing.Impl.Connection.MainLoopIteration() at RabbitMQ.Client.Framing.Impl.Connection.MainLoop() at RabbitMQ.Client.Impl.SessionBase.Transmit(Command cmd) at RabbitMQ.Client.Impl.RecoveryAwareModel.BasicAck(UInt64 deliveryTag, Boolean multiple)

We're using the nuget package with version 5.1.0.
Do we need to handle locking ourselves? Or is there a bug with the client? Or have we mis-configured something?

[Michael Klishin]

A prefetch count > 1 means there will be multiple deliveries in processing, so a scenario in which a resource

(e.g. a channel) is used concurrently becomes very likely.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Nick Lydon]

Thanks for the reply! The documentation only mentions that messages being delivered on the same channel will be delivered in order, but messages on different channels may be delivered in parallel. In concurrency considerations it also only mentions one background thread, but also states: "The one place where the nature of the threading model is visible to the application is in any callback the application registers with the library". I'm not sure what this means, as dotnet event handlers are single-threaded by default. Have I missed something, or could the documentation be updated to mention this?

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitm...@googlegroups.com.

To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.