[omniORB] Nested call blocked

[Peter Nyquist]

VisiBroker is smart and only opens one single connection
if possible... So omniORB will block on nested calls.

But I'm doing another type of nested call that works:

A --> call_x() --> B1
A <-- call_y() <-- B1

A --> call_x() --> B2
A <-- call_y() <-- B2

Even though call_y() from B1 to A is on-going, call_y() from B2 to
A works. What is the explanation for this? Is VisiBroker opening
a new connection for B2? Is it possible to use this fact to get
around the earlier problem?

Note: I'm still learning CORBA basics, so most of these issues are
new to me.

/Peter

> 
> 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