[jboss-user] [Clustering] - Re: JGroups timing call inomalities

[bstansberry@jboss.com]

JGroups is only going to allow one message at a time from a particular sender to proceed up the stack past UNICAST. This is needed to ensure message are delivered in order. So, only one RPC at a time.

There's a JGroups JIRA to add an API whereby the application can define the scope to which message ordering is applied; e.g. your app could say all messages associated with "LockA" must be ordered, but a message associated with "LockB" wouldn't have to wait for "LockA" messages.  But that won't be in JGroups 2.6.

How long does these RPCs take once the RPC is actually invoked on the coordinator? That's what's going to drive your throughput since the RPCs execute in series. Ah, you said 90ms, although AIUI that was for a remote client to get a response, so the actual server-side execution time is probably much less.

Worst case, lets assume it's 90ms. Your max throughput would be ~ 11 per second. If you are only executing 1 or 2 per second, serializing the execution shouldn't be adding more than an extra 90 ms delay to one RPC, and often wouldn't delay it at all.

The key thing here is the execution time of the RPC. With JBoss AS HTTP session replication, the same basic serialization of RPCs occurs at the JGroups level. Yet we handle hundreds of concurrent requests per node and thousands of requests per second. That's because the execution time of the RPC itself is very low.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261136#4261136

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261136