Multi-threading in Message Receiving in AMQP.Net 3.5?

Jul 1, 2015 at 8:49 AM
Hi,
We try to use Amqp.Net35 for Service Bus Queue on Sharepoint 2010.
We initiated the "ReceiverLink" as "this._receiver.Start(10, (r, m) =>..." and noticed that the incoming message is in sequence under the same Thread Id.
Hence, we wondering is Amqp.Net35 support Multi-thread on message callback in "ReceiverLink"? What does the "credit" and "SetCredit" in "ReceiverLink" meant for?
Thank you.
Jul 1, 2015 at 7:50 PM
The credit in the receiver link refers to the AMQP credit for the link. Refer to "2.6.7 Flow Control" in http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-complete-v1.0-os.pdf

Suppose you create a link to a queue that has many messages. By setting your link credit to zero you won't receive any messages even though there are plenty to be had. Later you set your link credit to 1. Now the sender on that link will send just one message and stop. Similarly setting the credit to 10 or 100 will allow the sender to start sending that many messages. By receiving and acknowledging messages the credit can be used to keep the incoming pipeline to the receiver full. A receiver would not want to set some high credit number, say 300, and have 300 messages coming in while the receiver plans to receive just one message and then disconnect. AMQP has a good set of programmable flow control settings that clients may use.

I'm not sure about the multi-thread question.
Marked as answer by raffless on 7/2/2015 at 6:31 PM
Jul 2, 2015 at 4:12 AM
crolke wrote:
The credit in the receiver link refers to the AMQP credit for the link. Refer to "2.6.7 Flow Control" in http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-complete-v1.0-os.pdf

Suppose you create a link to a queue that has many messages. By setting your link credit to zero you won't receive any messages even though there are plenty to be had. Later you set your link credit to 1. Now the sender on that link will send just one message and stop. Similarly setting the credit to 10 or 100 will allow the sender to start sending that many messages. By receiving and acknowledging messages the credit can be used to keep the incoming pipeline to the receiver full. A receiver would not want to set some high credit number, say 300, and have 300 messages coming in while the receiver plans to receive just one message and then disconnect. AMQP has a good set of programmable flow control settings that clients may use.

I'm not sure about the multi-thread question.
Thank for clearing the doubt of "Credit".

I guess I'll just process the message with ThreadPool for concurrent message handling. :)
Coordinator
Jul 2, 2015 at 6:52 PM
the OnMessage callback is invoked from a single thread which runs the connection's frame pump. If you create the connection with the async factory API, it could be different threads (from thread pool) but the callback is still sequential.

If your message processing takes longer time, it is not good to block the thread which processing the message. As you mentioned, you could implement parallelism by simply start the processing task and returning from the OnMessage callback immediately. Normally you may run into the risk of having too many concurrent tasks when the worker cannot keep up with the transport, but with AMQP, it is not an issue because of link flow control. The credit you issued controls how many messages you will get that are not accepted. When your processing task completes and you call receiverLink.Accept(message), the client will issue more credits to get more messages.

The other way to do multi-thread message processing is calling receiverLink.Receive() explicitly in a loop from multiple threads. You could use one receiver link or multiple links. With the first option you have competing consumers on the client, and with the second, you have competing consumers on the broker's queue.
Marked as answer by raffless on 7/2/2015 at 6:13 PM
Jul 3, 2015 at 2:31 AM
Thank you. It's all clear now. :)