[omniORB] omniORB 4.0.0 thread policy

[Duncan Grisby]

On Monday 20 January, "Michael Sturm" wrote:

> you are right, we are running omniORB on VxWorks. Of course we are 
> prepared to supply our experiences with this port as well as the 
> result of it. What kind of information do you want to have? What would 
> be the adequate platform to provide this information?

I would appreciate a patch file that shows any changes or additions
you made to the omniORB source, plus instructions on how the build
works on VxWorks. If it's small enough, please send it to the mailing
list. If it's quite large, please send it to me, and I'll integrate it
with the omniORB distribution.

> The second trace shows the scenario when our system runs into a hang-up:
> Here the second call 'begin' and the call 'rollback' ('rollback' does 
> close an open transaction as well as 'commit' does) are received by
> one single socket connection an then internally split up by omniORB 
> into multiple messages.

I'm not sure why it ever worked for you with the omniORB 4 beta.
There was a bug in the way pending calls were detected, meaning the
buffered calls were not triggering new worker threads. I don't think
that code changed between the beta and the release. Anyway, I've fixed
it in CVS.

Thanks for the bug report,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --