threading under omniORB.

[Sai-Lai Lo]

The threading model in omniORB is one thing that I'll definitely add to
the documentation.

>>>>> Bruce Israel writes:

> We're building a system which is going a server running multiple agents,
> each in it's own thread.  We'd like to have a client (in Java, using
> OrbixWeb) also mult-threaded, with each thread connecting to one of the
> server agents.  Is it possible in omniORB to implement a
> thread-per-object server model so that different objects aren't blocked
> when requests come in?

The GIOP protocol is asymmetric. For each network connection, one end
always acts as the client and the other end always acts as the server.  Only
the client end can initiate and only the server end can receive GIOP
requests.

To drive the GIOP protocol, omniORB is designed to achieve high performance
by removing unnecessary thread switching/multiplexing. At the same time,
maximum level of concurrency is provided by dynamically create one or more
connections to the same remote address space.

Here is an outline:

At the server end
-----------------

For *each* network connection, a thread blocks waiting for incoming requests.
When a request message arrives, the thread partially unmarshal the request
to the extend that it can identify which object the request is targeted.
It then performs an upcall to the stub-level dispatch routine specific to
the object. The dispatch routine further unmarshals the request and invokes on
the specified operation. The dispatch routine then marshals the results and
sends back the reply.

On return from the dispatch routine, the cycle begins again with the thread
blocks waiting for another incoming request.

When the thread is in the upcall, any requests arriving at that network
connection *will not* be processed.

Notice that requests coming in from other network connections are handled
by other threads dedicated to these connections concurrently. These
requests may be directed to the same object and hence more than one upcall
may be dispatched to the same object at the same time.


At the client end
-----------------

A thread calls on an operation of an object in a remote address space. This
is routed to the proxy object in the local address space. Through the proxy
object, the thread obtains *exclusive* access to a network connection,
marshals in the arguments, sends off the request, and blocks waiting for the
reply.  After the reply arrives and is unmarshalled, the thread *release*
the network connection and the operation is completed.

The network connection can then be used by the same or another thread to
issue requests to the objects in the same remote address space.

If during the time the thread holds exclusive access to the network
connection another thread invokes on an object (which may or may not be the
same object) that is in the same remote address space as the previous one,
a new network connection will be created on-the-fly and will be used
for delivering the new request. 

----------------------------------------------------------------------

> Is it possible in omniORB to implement a thread-per-object server model
> so that different objects aren't blocked when requests come in?

If both ends are omniORB, a request will not be blocked by other requests,
whether it is for the same or for different objects.

If the client side is not omniORB and if concurrent requests are
multiplexed by the client ORB onto the same connection, then the requests
will be processed in FIFO order. 

Having said that, it is quite possible to enhance the current server end
implementation to concurrently handle requests multiplexed onto one
connection. For example, the server thread can spawn off a new thread to
block waiting on the connection before it performs the upcall. Whether to
spawn off a new thread can be decided on a per object basis.

-------------------------------------------------------------------------

> We're building a system which is going a server running multiple agents,
> each in it's own thread.  We'd like to have a client (in Java, using
> OrbixWeb) also mult-threaded, with each thread connecting to one of the
> server agents.

IMHO, it may be worth checking whether OrbixWeb does indeed send off requests
from different threads concurrently, especially when the requests are all
directed to the same remote address space.

--------------------------------------------------------------------------

I hope this information is useful.

Regards,

Sai-Lai Lo

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