I always assumed that Codec would not be reentrant. Is that no longer
the case?
SOAPBindingCodec also maintains state for content negotiation so there
could be issues here as well.
Paul.
Oleksiy Stashok wrote:
> Hello.
>
> In FI case we have the bug reported for the mutlithreaded test.
> I guess it's because the FI Codec expects an XMLStreamReader to be
> associated with one thread at the same time. Which seems incorrect for
> the Fiber/Tube case.
>
> As I understand now for each new coming message
> StreamSOAPCodec.createXMLStreamReader() creates separate
> XMLStreamReader. In that case it works for sure for the Fiber/Tube case.
> I'm looking for some solution to optimize that for FI... I've read
> StreamSOAPCodec.createXMLStreamReader() method comment[1], but really
> didn't get the idea.
>
> Just want too add, that when tried FI codec to create each time new
> XMLStreamReader - bug didn't appear any more. But it doesn't seem as
> good solution?
>
> Thanks.
> WBR,
> Alexey.
>
>
> [1] // TODO: we should definitely let Decode owns one XMLStreamReader
> instance
> // instead of going to this generic factory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109