[omniORB] 50 ms delay with threadPoolWatchConnection=1 when there is a second remote call which blocks for a long time

[Barthel Marco (MPA/DS)]

Hi all,

I encounter a 50 ms delay on remote call processing on the server side using omniorb 4.0.3/win32 with threadPoolWatchConnection=1. BiDir-Connections/Threadpoolmode are in use. I need BiDir-Connections because of a firewall.

I know that the 50 ms delay is known to happen with threadPoolWatchConnection=0 which i wanted to use first.
(http://www.omniorb-support.com/pipermail/omniorb-list/2002-November/022393.html)

When there is a second upcall in the server which blocks for a longer time the threadPoolWatchConnection-Mode does not work as I would expect because only the last thread associated with the connection does the connection-watch. In my application there is almost always one upcall blocking for a longer time. This blocking upcall is used for event-polling from server to client - if there are no events the upcall blocks for 20 seconds and blocks again immediatelly because of a new upcall from the client.

Is there any portable way to put the connection under watch immediatelly after an upcall has finished?

Are there any suggestions how to release a thread from blocking in ::select on WIN32 ??

Thanks.

-marco