segunda-feira, 20 de fevereiro de 2012 08:41
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):
* TCP Connection that is longed lived
* TCP connection that is short lived
* Fiber/async/IO-completion port
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?
- Editado this is santa segunda-feira, 20 de fevereiro de 2012 08:47
Todas as Respostas
terça-feira, 21 de fevereiro de 2012 08:39Moderador
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.
segunda-feira, 27 de fevereiro de 2012 15:22Bump
quinta-feira, 22 de março de 2012 09:27Bump
quinta-feira, 22 de março de 2012 15:40Bump
http://www.CloudCasts.net - Community Webcasts Powered by Azure
quinta-feira, 22 de março de 2012 16:33
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.
sexta-feira, 23 de março de 2012 07:05
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?