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 [email protected] http://dankulp.com/blog
