Re: POA threading - more details

Hi Erez,

On Thu, Sep 29, 2005 at 10:27:34AM +0300, Erez Hadad wrote:
> Hi,
> 
> I've encountered a strange phenomenon related to POA threading: I have a 
> multi-threaded client that issues synchronous (e.g. not oneway) requests to a 
> collocated server. 
> At first, I used a POA with a thread pool in the server, using ORBacus 
> policies. Then, I decided that since the client is already multithreaded and 
> each thread issues synchronous invocations, then I should use the client's 
> thread to perform the collocated request inside the server as well, to save 
> thread resources. I implemented this by switching the POA threading policy to 
> dispatch_same_thread.
> The problem is, I got a considerably lower throughput when using the client's 
> threads than when using a separate thread pool for the POA. Seems as if an 
> "outsider" thread is required to do some additional processing compare to a 
> "home" thread.
> Can you explain why?
> 
> PS: I'm using ORBacus for Java 4.1.3, JDK1.4.2, Linux
> PPS: The client issues dynamic invocations (DII) - just synchronous, not 
> deferred or oneway.
> 
> Redgards,
> Erez Hadad

Let me give you some background into how Orbacus sets up a request...
- There is a base class StubImplBase which is the base stub class for
  static clients
- From StubImplBase is derived a MarshalStubImpl and a DirectStubImpl.
- The MarshalStubImpl is used to marshal/unmarshal a request/reply and
  transfer it to the wire
- The DirectStubImpl is actually a direct reference to the Servant
  implementation that exists in the POA.  It allows the static request
  to avoid marshaling and invokes directly on this servant.  This is how
  colocation is achieved and its very fast.

We chose this method of implementing collocation due to its incredible 
speed.  Marshaling and 'on-the-wire' is completely avoided.  The
downside is that collocation is not possible with DII since it would 
require knowledge of the stub/skeleton agreement in order to avoid 
marshaling and perform direct invocations.  Orbix on the other hand (and
take this with a grain of salt as I don't intimately know the inner
details of the Orbix source) uses some other method (perhaps
PortableInterceptors and Anys) that is slower in the static stub case
but allows it to utilize collocation with DII.  So its slower but more
general (still faster than operating throw the TCP-stack of the OS).  

So with that knowledge I think its fairly obvious why you are seeing
some more performance loss with your server now that you've switched
from the thread-pool model.  You now essentially have a single receiver 
thread in your server that receives a request, invokes it, returns the
reply and repeats.  With the thread-pool model you had a receiver thread
that received the message, queued it up, and went back to receiving
while some of the thread-pool workers invoked and replied.  In other
words, much more concurrent.

(For a more complete picture, see my article on Orbacus concurrency
models on www.orbzone.org.  It is a good overview of some of the
server-side concurrency models in Orbacus).  

Cheers.

-- 
Dion Picco, Software Engineer
IONA Technologies Inc.
Team Orbacus - Your CORBA Source
mailto:[email protected]
http://www.orbacus.com
_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html