Oleksiy Stashok wrote:
>
>
> Paul Sandoz wrote:
>> I always assumed that Codec would not be reentrant. Is that no longer
>> the case?
> I think the Codec itself is still not reenterant, but the 1 by 1
> associating XMLStreamReader with Codec could be problem. As the Codec
> passes XMLStreamReader after decode called farther by stack to point
> where Message is actually will transform to custom objects. And that
> transformation could occur at time when the Codec will try to be reused
> by another thread. That will mean the XMLStreamReader will be accessed
> simultaneously from two threads.
> And I try to find out the solution, which will let us somehow reuse
> XMLStreamReader in Codec and don't create the new one for each incoming
> message.
>
Ah, i see now. Hmm... this is indeed a problem. It is really important
to reuse FI StAX parsers (as you said to me the FI serializers can be
reused without any issue).
I presume the same reuse requirements are important for the XML StAX
parsers too. Same goes for more reusing streambuffers. i.e. it is all
about reusing memory.
Since things are passed off to a Message instance i am wondering if it
makes sense to add something to message which says "please release me...
let me go...", then we can have pools of stuff we can reuse.
Paul.
>> SOAPBindingCodec also maintains state for content negotiation so there
>> could be issues here as well.
> Hope Kohsuke or Jitu can have some idea about this issue w.r.t.
> Tubes/Fibers? :)
>
> WBR,
> Alexey.
>
>>
>> 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 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