As mentioned in the other email I was not saying this change was a risk (I
was actually the one who noticed this particular problem whilst discussing a
different issue with Andrew earlier). I was just saying that in general I
wouldn't be messing with accept modes at this point in the release process
normally, however taking this corrective action to fix the inadvertent
changes already introduced is a no-brainer.

Robbie.

-----Original Message-----
From: Rajith Attapattu [mailto:[email protected]] 
Sent: 08 March 2011 20:42
To: [email protected]
Cc: Justin Ross
Subject: Re: Request for the following commits to be included in 0.10

I disagree with item for #4 being a risk.
Andrew's commit was to restore a feature that I dropped when I committed rev
http://svn.apache.org/viewvc?rev=1076800&view=rev
Chances are that there might be apps out there that rely on NO_ACKNOWLEDGE
mode (even though it's not a standard JMS option).
All what Andrew has done is to use that ack mode to set a consumer level
default and if somebody has a destination level setting that will be
overridden.

Rajith

On Tue, Mar 8, 2011 at 3:33 PM, Justin Ross <[email protected]> wrote:

> Hi, Robbie.  I appreciate your caution regarding item 4, and I'm 
> prepared to revert that change if it's not truly low risk.
>
> Anyone else have an opinion on this item?
>
>
> On Tue, 8 Mar 2011, Robbie Gemmell wrote:
>
>  4. This specific change looks good to restore the prior behaviour, 
> though
>> in
>> general I wouldn't consider work around change of accept mode to be 
>> very low risk. I would suggest there should have been tests added to 
>> verify the behaviour of the original change that caused the issue 
>> though (same goes for all really).
>>
>> Robbie
>>
>> -----Original Message-----
>> From: Justin Ross [mailto:[email protected]]
>> Sent: 08 March 2011 18:08
>> To: [email protected]
>> Subject: Re: Request for the following commits to be included in 0.10
>>
>> Hi, Rajith.  I approved item 4.
>>
>> Robbie, would you indicate briefly up or down for 0.10 in the 
>> comments of
>> qpid-3109 and -2732?
>>
>> Justin
>>
>> On Tue, 8 Mar 2011, Rajith Attapattu wrote:
>>
>>  Hi Justin,
>>>
>>> I'd like the following commits to be included in the 0.10 release
branch.
>>>
>>> 1. http://svn.apache.org/viewvc?rev=1078961&view=rev  - QPID-3109  - 
>>> Fairly low risk.
>>>  This is a simple bug fix.
>>>
>>> 2. http://svn.apache.org/viewvc?rev=1078971&view=rev - QPID-2732  - 
>>> Low risk.
>>>  This is an addition to the initial commit made under this JIRA.
>>>  It adds default reliability modes and throws an exception for an 
>>> unsupported combination.
>>>
>>> 3. http://svn.apache.org/viewvc?rev=1079408&view=rev - QPID-2732  - 
>>> Low
>>>
>> Risk
>>
>>>   The reliability mode is used to mark a transfer unreliable and 
>>> that flag is used to determine if a transfer should be stored for 
>>> replay or
>>>
>> not.
>>
>>>   Again a fairly straightforward and low risk commit. However I have 
>>> asked Rafi to have a quick look at it as well.
>>>
>>> 4. http://svn.apache.org/viewvc?rev=1079402&view=rev - QPID-3127 - 
>>> Very low risk.
>>>    Fixes a bug in the initial commit for QPID-2732.
>>>    It just sets accept mode to NONE for NO_ACKNOWLEDGE.
>>>
>>> Regards,
>>>
>>> Rajith
>>>
>>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:[email protected]
>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:[email protected]
>>
>>
>>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
>


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to