What is the semantics of asynchronous receive in Service Bus?

Question

I was wondering about the properties of receiving from Azure Service Bus with regards to these concepts (without first going into wireshark or decompiling MSIL):

* Thread
* TCP Connection that is longed lived
* TCP connection that is short lived
* Fiber/async/IO-completion port
* Batching

As far as I understand the documentation and answers on this forum, a MessagingFactory has a long lived TCP connection to the broker that implements heartbeats and connection retry logic?

If this is not the case, what is the case?

As for short-lived TCP connections over HTTPS; do they happen each receive call? In that case; why would we have a long-lived TCP connection? Probably we wouldn't, so there's no long-lived connection. Then, how do we implement heart-beats and timing consumers out; is this explicitly handled through MF.Close()? In that case; why does Close fail with TimeoutException sometimes and how does one ensure valid state from a receiver perspective?

I want to get high throughput with OK latency. OK latency is about 30-50 ms. Each message payload is between 1 KiB and 3 KiB. How many receivers do I create? How many do I create per message factory if the MF handles some 'connection' as per above?

Given that I have multiple receivers; how many (interleaved concurrency) concurrent asynchronous operations should I have pending to maximize throughput? I still have batching enabled; so does this mean that if I have for example 2 MFs and 2 MessageReceivers, and I do 50 asynchronous BeginReceive to each of the message receivers at the very start - does this mean I get 50 IAsyncResults queued onto the internals of the framework that does batching; essentially negating the effect of having any asynchronous interleaving of requests?

What does timeout mean? Does it mean that it cancels the outstanding HTTPS request after the timeout:

a. if no data has started to be responded
b. if data has started to be responded but not fully transferred

and then; what are the semantics:

a. if data has started to be sent; this is data from a message (your own envelope internally?), this message or batch of messages is completely dequeued for the duration of the queue timeout?
b. if the server noticies that the connection is aborted before the response is complete, does it requeue those messages instantaneously?
c. if the server's last bytes of the response are in transit as the timeout expires (so TCP connection wasn't prematurely aborted); how does the server know that the message won't be consumed?

Answer 1

Hi,

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay.

Appreciate your patience.

Best Regards,

Ming Xu.

---

Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 2

Bump

Answer 3

Bump

Answer 4

Bump

---

http://www.CloudCasts.net - Community Webcasts Powered by Azure

Answer 5

You are asking 20 questions here, so those will be hard to answer in a good way since you are also making some assumptions you base some questions on that aren't necessarily correct. I also like to talk to folks with real names and not "this is santa", but that's your choice.

"TCP over HTTP" creates a long-lived pair of HTTP requests (one GET one POST) and keeps the alive for as long as possible. The resulting composite stream is treated just like a socket connection.

The messaging protocol is full duplex and the implementation is async. The synchronous functions are layered over the async ones. There's a connection pool managed by the MessagingFactory and traffic is multiplexed across multiple entities. Async operations result in async calls down into teh underlyign WCF TCP stack and further into thesocket stack and unmanaged IOCP, so we're running on I/O threads. The I/O threads obviously don't create concurrency on a socket, which is a serialized structure, so you're gaining better throughput and more parallelism with more sockets and thus more MessagingFactories, not more concurrent threads per-se.

When you call BeginReceive/Receive, we effectively register a receive credit in the broker for the session. There is no further traffic for that particular receive operation until the credit is satisfied either by timeout or by a message that can be retrieved. The session is kept alive by a separate ping. Credits expire when the session (socket) collapses and that's why you get an error on Receive once that happens - however, the session reconnects automatically and thus the receive itself stays valid and doesn't fault.

Clemens

Answer 6

Hello Clemens,

      You are telling the ServiceBus session will be kept alive by a separate ping .

                  Does the ping message will be consider as Service bus transaction?

                  How frequently this ping message will be delivered?

---

Navarajan