Hello again. I've finally gotten time allocated to deal with this issue (a bit of a delay, I know).. would it still make sense for me to fix this as I suggested originally, or has something else been done that makes this moot? Which new endpoints do you refer to? Regards, Sam
gnodet wrote: > > Agreed. Though we need the patch for the standard / multiplexing > providers. I'd rather finish the new endpoints (InOut support has not > been > written yet), but patches are always welcome. > > > On 3/20/07, samg <[EMAIL PROTECTED]> wrote: >> >> >> Hi, >> Am I right in thinking that a servicemix-jms provider endpoint can't be >> used >> in a situation requiring recovery from failure (with a system running on >> a >> single node)? From looking at the behavior in this kind of test, and the >> source of StandardProviderProcessor, it appears that the temporary queue >> that is created precludes the possibility of continuing to process the >> messages held in the non-temporary queue when the server goes down. It >> seems relatively simple to add a "reply-to" property to the Provider >> endpoint, allowing the use of another non-temporary queue- does this >> approach make sense? I'd be happy to do it and contribute a patch. >> Sam >> -- >> View this message in context: >> http://www.nabble.com/replies-to-JMS-and-recoverability-tf3431435s12049.html#a9565929 >> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Architect, LogicBlaze (http://www.logicblaze.com/) > Blog: http://gnodet.blogspot.com/ > > -- View this message in context: http://www.nabble.com/replies-to-JMS-and-recoverability-tf3431435s12049.html#a11198224 Sent from the ServiceMix - User mailing list archive at Nabble.com.
