Just create a patch against 3.1.1 so that we can apply it for next version and attach it to a JIRA issue please.
On 6/20/07, samg <[EMAIL PROTECTED]> wrote:
Okay, I'll make this change then. I'll need to do it in both the standard and multiplexing provider, in 3.1 and 3.1.1, correct? Thanks, Sam gnodet wrote: > > I was referring to the new endpoints that are being developed for next > (3.2) > version of ServiceMix. > They are not released yet, but are more stable and more powerful that the > previous one (jms:endpoint). > These are jms:provider and jms:consumer mainly. > > On 6/19/07, samg <[EMAIL PROTECTED]> wrote: >> >> >> 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. >> >> > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Principal Engineer, IONA > Blog: http://gnodet.blogspot.com/ > > -- View this message in context: http://www.nabble.com/replies-to-JMS-and-recoverability-tf3431435s12049.html#a11213183 Sent from the ServiceMix - User mailing list archive at Nabble.com.
-- Cheers, Guillaume Nodet ------------------------ Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
