On Monday 27 September 2010 4:42:55 am Andrew Dinn wrote: > On 09/24/2010 07:58 PM, Daniel Kulp wrote: > > I'm not sure I understand. Does the RelatesTo on the response properly > > match the message id of the request? If so, why is the MAPCodec not > > able to correlate the message? > > The problem is that when using ReplyTo/FaultTo the response may be sent > from one bus/exchange and the reply received by another. Your use fo > MessageID/RelatesTo to correlate request/response assumes that teh > response comes back to where it is sent to. This assumption may be invalid. > > > I guess my concern is around a potential memory leak if the MAPCodec is > > holding onto messages waiting for a response. But then again, I'm not > > sure I understand the issue. :-) > > Yes, this is one side of the problem -- the sender exchange fills with > garbage. The other side is that the receiver exchange drops legitimate > responses because they rae being received at a different location to the > sender. Unfortunately, proper support for WSA ReplyTo/FaultTo requires > that to be allowed.
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? 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. 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. Thoughts? Ideas? -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
