[omniORB] idle connection scanning: possible bug

[Dirk O. Siebnich]

I am sorry for the somewhat exaggerated subject line, because what I
have noticed is more in the category of a missing configuration error
guard, but anyway:

If I set up an inConScanPeriod that is less than twice the
scanGranularity, calls to oneways result in the server logging 

omniORB::logs(1, "dispatcher cannot stop idle counter.\n"); [GIOP_S.cc,
line 256 in CVS]

which in turn, if I am correct, results in a failure to process a given
upcall.

Browsing the involved sections of the source, I come to the conclusion
that this is due to the scavenger thread immediately responding to each
connection that is set to idle at the time, due to idlebeats == 1 as a
result of the configuration.

If I am correct, the problem here is that the discovery of idle
connections now races with the the sleeping scavenger thread, which
causes an unexpected behavior, in that connections may be found idle at
any time, instead of only after idling a minimum amout of time. This
problem becomes less visible if the factory between the ...ScanPeriod
and scanGranularity is sufficiently large, but say for someone that
wants to minimize thread thrashing and sets up a large value for
scanGranularity, this easily becomes a problem.

Therefore, I would like to propose two solutions:

A proper warning and explanation in the omniORB.cfg files, or - in my
opinion better - a code change that prevents idlebeats from being set to
less than 2.

What do you think?

Regards,
Dirk


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3223 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080408/3a910b51/smime.bin