[omniORB] Nested call blocked

Rob van der Leek r.vd.leek@fokkerspace.nl
Wed, 24 Jan 2001 13:05:12 +0100


My problem is kind of similar to the one Peter reported. I have already
posted a msg to the list about it. In short this is my situation:

1. Client1 -- push(event) --> EventChannel --- push(event) --> Server

2. Server incarnates an object factory, the server's push handler
creates a new object and calls some methods on that object. The method
invocations take some time to complete.

3. Client2 -- push(event) --> EventChannel --- push(event) --> Server

4. Now Client2 has to wait for the push handler to return (since the ORB
controlled thread policy in OmniORB is implemented as thread-per-object,
and there's only one server object).

Duncan Grisby corrected my assumptions in step 4 and told me OmniORB's
thread policy is thread per connection. Duncan also told me that the
EventChannel should open a new connection, so the server will use a
different thread. This thread model is exactly what I'm looking for
since I try to avoid threading as much as possible in my own apps...

_but_, my push server still blocks on the method invocation after
receiving a push event, other push events are queued untill the server
returns from the push handler. What am I missing here? Could it be
possible that all push events for a server are send from the
EventChannel using the same tcp connection (wild guess)?

Please let me know if you need a small test implementation to see how I
did things.

I'm using OmniORB 3.02 + OmniNotify 1.1b1 on a RH 6 Linux system.

TIA,
	Rob


Sai-Lai Lo wrote:
> 
> It may be the case that Visibroker is using the same tcp connection to sent
> the "display()" and the "push()" request. If that is the case, omniORB will
> not see the push request because there is only 1 thread dispatched to serve
> one connection. The thread is in the process of waiting for the reply to
> "request()".
> 
> Unless you can tell visibroker to have at most 1 outstanding request per
> connection, I'm afraid we have an interoperability problem here.
> 
> If you can, I suggest you break the long nested call chain. Either by
> 
> 1. in display() spawn another thread to do request() and then return
>    immediately.
> 
> OR
> 
> 2. in request(), spawn another thread to do push() and then return
>    immediately.
> 
> In omniORB4 currently under development, we'll address this issue.
> 
> Sai-Lai
> 
> >>>>> Peter Nyquist writes:
> 
> > We have a system with one client/server using omniORB on Linux (A)
> > and another client/server using Visibroker on Windows 2000 (B).
> 
> > In A there are two CORBA objects, Gateway and GatewaySession.
> > In B there are two CORBA objects, ConnectManager and ApplicationSession.
> 
> > At startup, Gateway receives a reference to ConnectManager from the naming
> > service.
> 
> > A client connects to the GatewaySession, which using Gateway's reference
> > calls newConnection(GatewaySession-ref) in ConnectManager. Connect manager
> > passes the GatewaySession-ref to ApplicationSession. No calls are now
> > "hanging".
> 
> > The following nested calls now occur:
> 
> > Visibroker side                                                  omniORB
> > side
> 
> > ApplicationSession -----> display(ApplicationSession-ref) ----->
> > GatewaySession
> > ApplicationSession <----- request() <--------------------------<
> > GatewaySession
> > ApplicationSession -----> push() ------------------------------> blocked in
> > omniORB.
> 
> > The push() call does not reach the GatewaySession code.
> 
> > It seems that since omniORB is already processing the display() call, it
> > cannot handle the
> > nested push() call. Is this a correct analysis of the problem? Is this a
> > known problem?
> > Can we set up omniORB to somehow handle this type of nested call?
> 
> > When we run VisiBroker on both sides, it works just fine. Running JavaORB ->
> > omniBroker still
> > shows the same problem.
> 
> > Thanks
> 
> --
> Sai-Lai Lo                                   S.Lo@uk.research.att.com
> AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com
> 24a Trumpington Street                Tel:   +44 1223 343000
> Cambridge CB2 1QA                     Fax:   +44 1223 313542
> ENGLAND