[omniORB] omniORB 4.0.0 thread policy

[Michael Sturm]

This is a multipart message in MIME format.
--=_alternative 003514E6C1256CAD_=
Content-Type: text/plain; charset="us-ascii"

Hi,

we are working with omniORB 4.0.0 together with our own adaptation for 
VxWorks operating system in an embedded application.

As long as we used omniORB 4.0.0beta we did not have any problems with 
this application. Since we switched to omniORB4.0.0
it seems that in some cases received remote calls are dipatched to the 
omniORB's worker threads (dedicated worker thread, 
temporary worker threads) in another fashion than they were before. The 
following example explains the problem:

call1: StartTransaction-A
            ..............
            ..............
call2: StartTransaction-B
call3: EndTransaction-A

In the above scenario call2 results in a regular blocking as only one 
transaction is allowed to be active in our system. This blocking should 
not
rest for a long time as call3 allways will be sent immediately after call2 
and forces its unblocking. We now find situations where call3 is
dispatched to a temporay worker thread by the ORB. In this case the 
autonomous thread serving call3 forces an immediate unblocking of call2
and everything works allright.

In other situations call3 is not dispatched to a temporary worker thread. 
In contrast to this it is dispatched to the dedicated worker thread after
expiration of an internal timeout which was started by call2. This 
internal timeout produces a (temporary) hangup of our system.
It seems that the described unwished scenario allways occures in case 
call2 and call3 are contained in one single GIOP-message which is 
internally split up into multiple messages. In case call2 and call3 are 
received as separate GIOP-messages call3 is dispatched to a temporary 
worker thread and then this autonomous thread serving call3 immediately 
terminates the blocking of call2 which means that our system does not 
hang.

Does anybody have an idea or hint what might be the reason for this 
effect? Note: We did not have these problems as long as we used
omniORB 4.0.0beta, omniORB is configured with default settings.

Regards,

Michael Sturm, Acterna Eningen GmbH
--=_alternative 003514E6C1256CAD_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">we are working with omniORB 4.0.0 together with our own adaptation for VxWorks operating system in an embedded application.</font>
<br>
<br><font size=2 face="sans-serif">As long as we used omniORB 4.0.0beta we did not have any problems with this application. Since we switched to omniORB4.0.0</font>
<br><font size=2 face="sans-serif">it seems that in some cases received remote calls are dipatched to the omniORB's worker threads (dedicated worker thread, </font>
<br><font size=2 face="sans-serif">temporary worker threads) in another fashion than they were before. The following example explains the problem:</font>
<br>
<br><font size=2 face="sans-serif">call1: StartTransaction-A</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ..............</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ..............</font>
<br><font size=2 face="sans-serif">call2: StartTransaction-B</font>
<br><font size=2 face="sans-serif">call3: EndTransaction-A</font>
<br>
<br><font size=2 face="sans-serif">In the above scenario call2 results in a regular blocking as only one transaction is allowed to be active in our system. This blocking should not</font>
<br><font size=2 face="sans-serif">rest for a long time as call3 allways will be sent immediately after call2 and forces its unblocking. We now find situations where call3 is</font>
<br><font size=2 face="sans-serif">dispatched to a temporay worker thread by the ORB. In this case the autonomous thread serving call3 forces an immediate unblocking of call2</font>
<br><font size=2 face="sans-serif">and everything works allright.</font>
<br>
<br><font size=2 face="sans-serif">In other situations call3 is not dispatched to a temporary worker thread. In contrast to this it is dispatched to the dedicated worker thread after</font>
<br><font size=2 face="sans-serif">expiration of an internal timeout which was started by call2. This internal timeout produces a (temporary) hangup of our system.</font>
<br><font size=2 face="sans-serif">It seems that the described unwished scenario allways occures in case call2 and call3 are contained in one single GIOP-message which is </font>
<br><font size=2 face="sans-serif">internally split up into multiple messages. In case call2 and call3 are received as separate GIOP-messages call3 is dispatched to a temporary </font>
<br><font size=2 face="sans-serif">worker thread and then this autonomous thread serving call3 immediately terminates the blocking of call2 which means that our system does not hang.</font>
<br>
<br><font size=2 face="sans-serif">Does anybody have an idea or hint what might be the reason for this effect? Note: We did not have these problems as long as we used</font>
<br><font size=2 face="sans-serif">omniORB 4.0.0beta, omniORB is configured with default settings.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br>
<br><font size=2 face="sans-serif">Michael Sturm, Acterna Eningen GmbH</font>
--=_alternative 003514E6C1256CAD_=--