Hi Andrew,
I actually had a brief chat about this with Dan yesterday. The main
reason seems to be in WS-RM needs, but I still need to look at the
details (to understand what actually needs to be copied from one
exchange to the other). Besides that, there're probably other
requirements related to visibility of context properties.
Cheers
Alessio
On 09/29/2010 10:53 AM, Andrew Dinn wrote:
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?
regards,
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.
--
Alessio Soldano
Web Service Lead, JBoss
