cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Dinn <>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Wed, 29 Sep 2010 08:53:25 GMT
Hi Dan,

I am  afraid I have much shallower knowledge of the CXF code than 
Alessio so I hope you will forgive me asking a rather simple-minded 
question. Could you explain why CXF needs to perform correlation of 
outgoing requests and incoming responses?


Andrew Dinn

On 09/28/2010 09:33 PM, Daniel Kulp wrote:
> On Tuesday 28 September 2010 7:26:24 am Alessio Soldano wrote:
>>    Hi Dan,
>> On 09/27/2010 08:25 PM, Daniel Kulp wrote:
>>> Hmm.....   I wonder if we can tackle some of these things kind of piece
>>> meal, in steps:
>>> 1) Scenario one is a single Bus, but multiple MAPCodec's.   This should
>>> be fairly easy.  If the MAPCodec stores it's storage map as a property
>>> on the Bus, then multple MAPCodecs could share the storage and the
>>> problem would be solved  for this usecase, right?
>> Right
>>> 2) Scenario two is a single JVM/classlaoder with multiple bus's.  This is
>>> similar to (1), but the storage could be pre-configured and shareable.
>> Yes. Btw this is more or less the scenario we're on right now, as we
>> could have this storage as a shared facility provided by CXF libraries
>> which can be seen by all apps using them.
>>> 3) Scenario three would be multiple apps/jvms/classloader.  This is
>>> trickier. One solution would be to allow configuring in a distrubted map
>>> implementation for the storage.
>> Yes, this is indeed trickier... and would deal with client and final
>> response endpoint running on different jvm/classloader.
>> IOW what you're suggesting here is that this might basically be a matter
>> of having the user configure the storage with the scope/visibility he
>> needs, right?
> Yea.  That's kind of what I was thinking.   This MAY be combinable with your
> disabling of the correlation check so if the message cannot be correlated in
> the current storage, just let it through like you originally tried.   To avoid
> the memory leak, we could timestamp the outgoing exchange and periodically
> purge the exchanges based on some sort of configurable timeout.   That would
> at least cover MOST of the issues.


Andrew Dinn
Senior Software Engineer, JBoss
Red Hat UK Ltd
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod 
Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
(USA)  and Brendan Lane (Ireland)

View raw message