On 05/12/12 17:03, jaybytez wrote:
So to add a little detail to this, we have the following:
One War
1) DefaultMessageListenerContainer -> SubscribeService -> External Service
Wrapper -> External Service
So our SubscribeService is the business logic of pulling messages off the
queue. Our External Service Wrapper is a service that wraps our third party
call because it is XML/HTTP, this is a local instance of a class. Within
the local instance of the External Service Wrapper we make a WebClient call
with information from External Service. We have problems with the
Thread/Cookie Mgmt when done this way.
Interesting thing is when we split the code into two wars and do the
following:
Two War
1) DefaultMessageListenerContainer -> SubscribeService (Web Service Call to
other WAR) ->
2) External Service Wrapper -> External Service
When the External Service Wrapper lives in it's own war, managing it's own
threads, and the SubscribeService calls it remotely (as opposed to using it
as a local instance), we have no Thread/Cookie Mgmt issues with WebClient.
interesting
So maybe the question really is how the DefaultMessageListenerContainer
min/max threads effects the threading of WebClient (stateful invocation).
I'd still say that given you create WebClient on the stack it does not
matter how it is being called. I'm assuming that HttpConduit is not
doing its own cookie management now, right ? (I'm not sure yet how it is
supposed to work in the multithreaded case - but lets review this
particular issue later)
Please check the logs - that can help shedding some light on the cause
of this issue
Cheers, Sergey
--
View this message in context:
http://cxf.547215.n5.nabble.com/WebClient-multithreading-within-a-DefaultMessageListenerContainer-tp5719525p5719752.html
Sent from the cxf-user mailing list archive at Nabble.com.
