Looks good - I'll commit it later tonight -- Rob
On 8 January 2014 21:54, Timothy Bish <[email protected]> wrote: > On 01/08/2014 03:41 PM, Rob Godfrey wrote: > >> On 8 January 2014 21:27, Fraser Adams <[email protected]> >> wrote: >> >> On 08/01/14 18:55, Rob Godfrey wrote: >>> >>> Hi Uli, >>>> >>>> To enable synchronous publishing you need to either set the Java system >>>> property "qpid.sync_publish" to true, or have sync-publish=true as one >>>> of >>>> the URL options in your connection URL. >>>> >>>> I agree it should be the default, and we can look to change this in a >>>> future release. >>>> >>>> Hmm, I'd really rather you didn't do that. Async behaviour has been the >>> default behaviour with Qpid from year dot. so changing it is pretty >>> likely >>> to bite someone nastily. >>> >>> I'd agree that async behaviour technically means that by default Qpid >>> breaches JMS guarantees, but TBH I think it's a little late in the day >>> now >>> to be going switching the default. It's also make the default behaviour >>> inconsistent with qpid::messaging which doesn't seem ideal. >>> >>> >>> Given this is a totally separate client, (and is vastly different in >> many >> other ways - like different connection URLs, different address formats, >> etc.) and it's probably being used more widely against non-qpid >> brokers/services than it is against Qpid right now, then I'm not sure I'm >> too worried about refleting the behaviour of the AMQP 0-8/9/9-1/10client. >> I think the bigger issue in switching the default right now is that it >> would seem that it would break anyone trying to use it with ActiveMQ. >> >> >> As we've discussed before not everyone has guaranteed delivery right up >>> there at the top end of things they give a damn about, in my case it's >>> all >>> about performance and I can take the hit if I lose the odd message - >>> plenty >>> more where they came from :-) I probably wouldn't be wildly amused to >>> upgrade to Qpid version "x" only to find a massive performance regression >>> that might force me to get a non-trivial number of clients to change some >>> bit of config. or other. >>> >>> >>> The "intelligent" change would be to only use syn publishing with >> persistent but non-transactional messaging. If you are using transient >> you >> clearly aren't looking for guaranteed delivery anyway. If you are using >> transation, you get your guarantee at the commit. This is the "expected" >> behaviour for JMS (though most implementations offer a switch to turn it >> off so people can get better performance... in which case you have to >> wonder why they are using persistent messaging in the first place).... >> >> Anyway given the issues with ActiveMQ - I won't be changing it for the >> moment anyways. >> >> -- Rob >> >> >> Frase >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> I submitted a patch for the issue that was opened for this thread: > > https://issues.apache.org/jira/browse/QPID-5455 > > It enables sync sends either when the flag is set or the JMS DeliveryMode > that was requested is PERSISTENT and there is no current TX in progress. > Testing against a 0.26-SNAPSHOT with the fix and an ActiveMQ 5.10-SNAPSHOT > things seem to be working fine. > > -- > Tim Bish > Sr Software Engineer | RedHat Inc. > [email protected] | www.fusesource.com | www.redhat.com > skype: tabish121 | twitter: @tabish121 > blog: http://timbish.blogspot.com/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
