Re: Reason for omniORB imposed latency when handling multiplexed requests on a server connection?

Duncan Grisby wrote:
>>I've noticed that giopServer::notifyWkPreUpCall always calls
>>setSelectable with now = 0.  This means that the select loop is not
>>immediately notified that the server connection is readable.  Since
>>the main select loop has a fixed wakeup timeout of 50ms, up to that
>>amount of latency is seen before a second request on the same server
>>connection is recognized and processed.
>>
>>Is there a particular design reason for this added latency?  Otherwise
>>I'm strongly tempted to change notifyWkPreUpCall to set now = 1 and
>>get immediate service for the connection.
> 
> It's a balance between different concerns. There are two common usage
> patterns that influenced the design. First, it is often the case that
> each connection is used by only one client thread at a time. In that
> case, there won't be any interleaved calls. The second common pattern is
> that a client sends lots of small oneway calls that complete quickly on
> the server. In that case, several calls can arrive very rapidly, and
> it's best to service the calls from just one thread rather than allowing
> an explosion of threads to handle all the calls.
> 
> Also, signalling the select thread to wake up immediately is a pretty
> heavy-weight thing, and leads to thread switching during operation
> dispatch. In most applications, it's rare to need the connection to be
> immediately watched, so it's left to the timer.
> 
> Having said all that, if it's better for your application to always kick
> the select thread in notifyWkPreUpCall, I don't think it'll break
> anything to change the code. Note that on Windows setting now to true
> has no effect since it doesn't have a convenient way to wake up the
> select thread.

Yes, those are rational reasons.  What we really need are user settable 
tuning parameters for both the 50ms timer and for immediate vs delayed 
selectable handing.  Then I can get what I want without modifying the 
source code.

-- 
Jon Biggar
Levanta
[email protected]