[omniORB] thread pool vs. thread per connection

[Duncan Grisby]

On Tuesday 26 November, baileyk@schneider.com wrote:

>      I found that the omniAsyncInvoker has a 10 second idle timeout for the
> threads in the pool.  Meaning that any thread not used for 10 seconds will
> die.  This explains the excessive thread creation.  I'd run a test, say 5
> concurrent calls, and see 5 threads created.  Then I'd look over the
> results (for more than 10 seconds) and run again, and again see 5 threads
> created.  Under continuous load, the thread creation may not be so bad, but
> I think the 10 second timeout should be configurable.  In reality usage
> spikes may be expected ever few minutes, not seconds.

I agree that it's a good idea to make the 10 second timeout
configurable. I'll do it before the 4.0.1 release.

>    I think I've tracked it down to the logic in
> SocketCollection::setSelectable().  There's a comment
> 
>     // XXX poke the thread doing accept to look at the fdset immediately.
> 
> But no code follows this to do such a 'poke', which is evidently why
> there's an XXX in the comment.  A future planned enhancement?

Yes, that's exactly what's happening. The reason it hasn't been done
yet is that, as you have discovered, it's not at all easy to do in a
cross platform way. At some point, I intend to look into whether it's
possible to achieve the same effect without having to trigger the
thread doing select(). I'm open to suggestions...

Is there a good reason that you don't want to use the
threadPoolWatchConnection setup?  That way, sequences of calls from a
single client are all done by the same thread, without having to wait
for the select thread to get involved. The policy reduces the
concurrency between clients, but given that they are all accessing the
same data, they can't access it concurrently anyway. With something
like the Naming service, a single client isn't likely to make a very
large number of calls without a break, so it's only a transitory
effect.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --