Kohsuke Kawaguchi wrote:
> 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.
>
Currently in JAX-WS the parsers (XML and FI) are stored in thread
locals, which results in the same thing as being stored on the pipes if
pipes are essentially thread local.
A decoder could use two types of parser, XML or FI. It is necessary for
the decoder to choose the parser implementation based on the content
type, but it should not be necessary to keep both around on the same pipe.
In this respect I think having a parser factory mechanism is very
useful. It would also hide the little details of using SJSXP and FI
specific reset functionality as there is no standard way to reset an
XMLStreamReader.
Paul.
> 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.
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109