Vivek Pandey wrote:
> I think this design choice is more driven because of some expensive
> objects. I wonder with the pipes, encoders/decoders being non-reentrant
> how many of such instances will be there, for example if client is
> invoking lots of thread!
If you are really making 10 concurrent invocations, even if the
pipelines are completely stateless, you'd be using 10 parsers, 10
buffers, 10 everything. So it's going to be expensive memory-wise anyway.
The only additional cost we are paying by having non-reentrant pipes are
the pipe objects themselves, which I think are generally much smaller
(compared to parsers and buffers that we want to keep around.)
And I think benchmarks tend not to use those one-shot threads, and if
each thread is invoking a service as fast as they can, I think the
object reuse will really give them a good performance boost (Imagine a
Niagara system!) The same thing applies to the server.
I think you are right that we need a good caching strategy for pipes
(both on client and server), but with non-reentrant pipes there only
need to be one cache strategy (in the proxy and in the servlet), instead
of having each pipe invent their own.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com