[omniORB] why multiple async workers for one connection

[Renzo Tomaselli]

Hi all,
    within the search for a solution to our AIX problem - which I described
in a previous posting - I wonder if anybody can explain me why a simple
client, a python script performing a tight loop on the same obj ref. method,
ends up with multiple worker threads in the server.
I read the theory of operation at the bottom of giopserver.cc, for the
thread-per-connection model: indeed it seems that while being busy in an
upcall, my server accepts a new connection from the same client which turns
out in a new omniAsyncWorker being created. I thought that such
single-threaded/simple-flow client would always work along a single
connection for its entire life. I followed this behavior while debugging the
server under Windows.
This issue seems related to my crash on AIX, where there is always a fixed
pattern: an incoming call crashes because a thrown exception is invalidated
when such a call is the very first one after a new AsyncInvoker is created
(which occurs after a random number of successful calls).
The trace log always ends up with:
...
omniORB  inputMessage: from giop:tcp:10.10.15.47:35853 78 bytes
omniORB  sendChunk: to giop:tcp:10.10.15.47:35853 53 bytes
...< repeated many times>
omniORB  AsyncInvoker: thread id = 10 has started. Total threads = 4
omniORB  giopWorker task execute.
omniORB  inputMessage: from giop:tcp:10.10.15.47:35853 78 bytes
pure virtual method called
./axserver.sh: 20634 IOT/Abort trap(coredump)

Basically I wonder why this giopWorker is created along the way, while I
guess it will service new input messages in spite of existing workers.
Thanks,

Renzo Tomaselli