[omniORB] Nested call blocked

[Rob van der Leek]

So, if two push clients trigger each an event for the same server and
the push handler takes a few seconds to complete, OmniORB would open 2
connections from the EventChannel to the push server (and thus creates
two connection handling threads at the server side)?

I'll try to show what I mean with the examples from the Notify package.
I suspend the push handler for a few seconds:

examples/sample_functions.cc:
...
void
sample_consume_any_fn (const CORBA::Any& event,
                       const char* obj_name,
                       const CORBA::ULong event_num,
                       CORBA::Boolean verbose
                       )
{
  CORBA::ULong ul;
  if (event >>= ul) {
    if (verbose) cout << obj_name << ": event data = " << ul <<
        ", event count = " << event_num << endl;
    sleep(5);
  } else {
    if (verbose) cout << obj_name << ": event data not known (not a
ULong), event count = " << event_num << endl;
  }
}
...

I compile the legacy_push_consumer and start it in an xterm:
$ ./legacy_push_consumer -d 6 -v

Then I simultaniously start two push client in separate xterms:
./legacy_push_supplier -d 3 -m 1000 -v

The consumer output is:
Waiting for desired # of events
legacy_push_consumer: event data = 1, event count = 1 # 5 sec. wait
legacy_push_consumer: event data = 1, event count = 2 # 5 sec. wait
legacy_push_consumer: event data = 2, event count = 3 # ...
legacy_push_consumer: event data = 2, event count = 4
legacy_push_consumer: event data = 3, event count = 5
legacy_push_consumer: event data = 3, event count = 6

The whole run takes 30 seconds to complete, from which I conclude that
the events are serialized at the server side.

	regards, rob

Sai-Lai Lo wrote:
> 
> Your scenerio is different. As a client, omniORB do not let more that one
> call outstanding per connection. If it needs to dispatch 2 calls to the
> same address space, it opens 2 connection if necessary.
> 
> In the previous mail, the client is not omniORB, hence the difference.
> 
> Sai-Lai
> 
> >>>>> Rob van der Leek writes:
> 
> > 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.
> 
> --
> 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