[omniORB] Disappearing oneway calls: Maybe I found the bug

[Jan Lessner]

Hello all
A few weeks ago I mentioned that we have problems with disappearing
oneway calls. We spend quite a lot of time to analyse the problem and we
have a new idea what it may be about. So maybe anyone being concerned
with the deep-down issues of omniORB could say if I'm right:

In our application scenario we are using two cooperating servers which
transmit both two-way and one-way calls in both directions. Consequently
the involved file descriptors are registered as outgoing and incoming
connections on both sides. Sometimes the check for idle incoming and
outgoing connections are performed very quickly one after the other
without any message dispatching occuring in between. For connections
being registered as both incoming and outgoing, the first check resets
the heartbeat flag and the second one finds it reset, assuming the
connection to be idle. It therefore shuts down the Strand, causing all
data to get lost which is received while the Scavangers are running.

This is what it looks like from out investigations. As you see it takes
a few complicated circumstances and some real bad luck in timing. I
found out that it's usually not a serious problem to shut down a
conection which is in fact pretty busy. Both receiver and sender just
get a new connection assigned when they need it. This works fine, so
that it actually looks like a single (or two maximum) message got lost
while everything worked well before and also *afterwards*.

May this be a reason?

Regards,

	Jan Lessner, C-LAB