qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Serious Bug in AMQP 1.0 JMS Client with persistent messages
Date Wed, 08 Jan 2014 21:12:40 GMT
Looks good - I'll commit it later tonight

-- Rob


On 8 January 2014 21:54, Timothy Bish <tabish121@gmail.com> wrote:

> On 01/08/2014 03:41 PM, Rob Godfrey wrote:
>
>> On 8 January 2014 21:27, Fraser Adams <fraser.adams@blueyonder.co.uk>
>> 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: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>>>  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.
> tim.bish@redhat.com | www.fusesource.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message