Suspending a method execution

[Gary D. Duzan]

In Message <34FDAB02.5DBF5581@tts.dowjones.com> ,
   Kaisheng Du <kxd1483@tts.dowjones.com> wrote:

=>Gary D. Duzan wrote:
=>
=>> In Message <34F70B6E.9B3@c-lab.de> ,
=>>    Jan Lessner <jan@c-lab.de> wrote:
=>>
=>> =>Hello all
=>> =>A while ago I learned that omniORB creates a separate thread for
=>> every
=>> =>single implementation object for its request dispatching.
=>>
=>>    The basis for your question is flawed. This is not, in fact, the
=>> threading model used in OmniORB. Rather, it uses a thread-per-client-
=>> connection model. There can be from zero to an arbitrarily large
=>> number
=>> of threads associated with an implementation object at any given time,
=>>
=>> depending on the number of clients operating on it. For details see
=>> the
=>> documentation with OmniORB 2.4.0, the chapter on Connection
=>> Management,
=>> and the section entitled The Model.
=>
=>It only says that a new connection will be set up if concurrent calls
=>are made to the server.  It didn't imply that
=>the server will look up who is calling and give the caller the thread
=>belonging to him, if it exists. It seems me that
=>if the same client tries to make two calls back to back, OmniORB  may
=>create two different connections to the server.

   Right. Generally you have one thread waiting for new connections
which starts one new thread for each IIOP connection. If the client
decides that it needs another connection it can start another, but the
server just treats it as any other new connection. The
client-connection server threads actually block on the connection,
waiting for incoming requests. If it gets one, the thread is used to
unmarshall and dispatch it. Since it is a block/receive/execute/reply
loop for each client-connection thread on the server, there is no need
to "look up who is calling" for it to reuse the thread.
   The paragraph from the doc you really want to look at is:

	On the client side of a connection, the thread that invokes on
	a proxy object drives the IIOP protocol directly and blocks on
	the connection to receive the reply. On the server side, a
	dedicated thread blocks on the connection. When it receives a
	request, it performs the up-call to the object and sends the
	reply when the upcall returns. There is no thread switching
	along the call chain.

   Sai-Lai posted a pretty good message on this subject to the list a
while back, as well. It is available from the list archives at:

  http://www.orl.co.uk/omniORB/archives/1997-Jun/0048.html


					Gary Duzan
					GTE Laboratories