oneway

[Sai-Lai Lo]

>>>>> Melih Ercan xe44 9777 writes:

> As far as I know, the purpose of oneway is to achieve an asynchronous
> call (no response-fire and forget-nonblocking call) to a server object
> method.

> Now imagine that there is a server object method whose execution takes
> 5 minutes when called.

> When a client which resides on another address space activates this
> method with oneway, the nonblocking will work fine as this call will be
> routed to the proxy object which will send the request to the target
> address space and will return immediately.

> But if the target object is in the same address space, the call will be
> done to the real object which will return to the client after 5 minutes.
> What a nonblocking call!!!


I think there are two issues here:

1. Is oneway really nonblocking?

Because IIOP is layered on top of a reliable stream transport, there is no
guarantee that a oneway call will not be blocked by the flow control
mechanism of TCP/IP. For example, when the machine at the other end goes
down, oneway calls will be blocked (how quickly depends on how
often and how much data are sent). 

If an application really wants a guaranteed end-to-end nonblocking
semantics, I think the ORB has to handle the call differently and should be
told of the Quality of Service (QoS) requirements and selects the
appropriate transport and threading model. At the moment, there is no
standard API to allow applications to exercise QoS control on the ORB.
Part of our work here at ORL is to extend omniORB to provide QoS control at
the application level. I could write about this some other time.

2. Invocation semantics of co-located objects

For efficency reason, omniORB and (I believe) other commercial ORBs use the
same thread that invokes on an object reference to perform the upcall into
the object implementation. IMHO, it is a reasonable approach except in the
your example the caller sees a different behaviour if the object
implementation is actually in another address space.

In your example, if the object implementation knows it is going to
go away for 5 minutes before returning and non-blocking behaviour is
required, perhaps a better implementation is to have a separate thread to
do the time-consuming bit and leave the thread doing the upcall to just
deposit the necessary information and can then return.

When implementing an object that might be used by co-located as well as
remote clients, I think it is necessary to keep in mind the threading
behaviour. Otherwise there might be some unwelcomed surprises waiting to
spring at you.

I should also point out that omniORB_2.2.0 has a few deficencies in
supporting co-located clients and object implementations. 

1. _dispose() does not get rid of the object implementation until all the
   object references in the same address space are released. On the other
   hand, object references held in a different address space does not have
   that effect.

2. When an object reference is unmarshalled and the ORB determines that it
   is an object in the same address space, it will try to locate the
   object. If the object is not found, it throws a SystemException. On the
   other hand, if the object reference points to an object in a different
   address space, the ORB would happily create an object reference without
   checking if the object actually exists. If the object does not exists, a
   SystemException would be raised only when the object reference is
   invoked.

I have sort out (2) in the coming release so that the behaviour is the same
whether the object is local or remote. (1) is more difficult and a long
term solution involves introducing an indirection in dispatching calls to
co-located objects. I'm going to sort that out when I start doing the
Portable Object Adaptor.

Regards,

Sai-Lai

-- 
E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research Lab
                                        |       24a Trumpington Street
Tel:            +44 223 343000          |       Cambridge CB2 1QA
Fax:            +44 223 313542          |       ENGLAND