cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Tue, 28 Sep 2010 20:33:24 GMT
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.

Daniel Kulp

View raw message