Re: POA threading - more details - RE-OPEN ISSUE

Hi Dion,

It seems I need to re-open this issue again since thinking more about it 
convinced me that your answer does not explain it. You see, the 
multi-threaded client issues *synchronous* collocated DII requests. This 
means that each client thread, whether it waits for the POA pool thread or 
processes the request inside the POA by itself, does nothing else. There is 
no concurrency to be gained in the case of using a POA thread pool compared 
to the case of a a same_thread dispatch strategy. Still, using a POA thread 
pool to process requests yields much better throughput than using the 
client's threads. This is what lead me to persist on the possibility of 
thread discrimination in the first place. Note that I'm using JOB, so JTC is 
irrelevant. Can you think of any other reason why this would happen?
(JOB-4.1.3, JDK-4.1.2, Linux)

I remembered that point a little late - sorry for troubling you again.

Sincerely,
Erez Hadad

On Thursday 29 September 2005 19:30, Dion Picco wrote:
> 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.
_______________________________________________
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