[omniORB] Premature Connection termination?

[Norrie Quinn]

We are using a modified version of omniORB2.6.1 and are currently upgrading
to 3.0.2.

Having observed a problem in omniORB2 2.6.1 which causes omniORB to
continually close and open TCP connections, it looks like 3.0.2 may do the
same.  Lets say we have two objects implemented in separate multi-threaded
server processes:

interface A {
  void foo(in B b);
};

interface B {
  void foo();
};

1) A client calls A::foo, passing a B reference.
2) The implementation of A::foo calls B::foo.
3) As the process A->B Rope is reference counted by object references, the
Rope is considered idle once these calls are complete (assuming that the A
server process has no other references on the B server process).
4) The client calls A::foo again.
5) As an object reference is passed, createObjRef iterates all Ropes to
determine wheather the reference is local or remote.
6) As the A->B Rope is still idle, Rope_Iterator::operator() flags all
Strands in the Rope to die (a ripper thread does the actual deletion in
3.0.2).
7) When B:foo() is called a new Strand is established.

Depending on threading, the result can be a close and open of a connection
for every call that follows this pattern.  Even with several threads running
in Server A, we hit this frequently.

Three Questions:
Has anyone seen this or seen a fix?
Would it not be better to leave Strand cleanup to the scavenger only
(Particularly between Server components where the load, threads and
therefore rope width are constantly high)?
Although the Strand lifecycle and scavenver code has changed significantly
in 3.0.2, could the same problem occur?

We are looking at fixing this in 2.6.1 for ourselves by leaving the
_setStrandIsDying() call to the scavengers.  So the
Rope_Iterator::operator() method would leave an idle Rope with strands as
is.  Only when a Rope and all its Strands have been idle for a scavenger
cycle would they be requested to close.

Regards
Norrie