On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim <g...@redhat.com> wrote:
> On 04/20/2011 02:38 PM, Rajith Attapattu wrote:
>>
>> While the root cause for both these items have been present in 0.8
>> (and perhaps before for QPID-3216) these issues are *more likely* to
>> happen in the current release than in 0.8
>> In that sense they are regressions, and certainly from a users pov of they
>> are.
>
> What is that based on? The fact that we've seen these test failures? Or
> identification of specific changes first included in 0.10 that make this
> worse?

All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I
stand to be corrected on this).
But somehow this became more visible now.
My suspicion is that some other changes in that time frame has made
this issue more likely.
Unfortunately I am unable to pin point what exactly those changes are.
The fact that our tests are failing is not helping either.

>> I think recent changes in the client and broker may have made these
>> issues happen more likely.
>> While r1092510 may have caused QPID-3216 to happen more readily there
>> may be other triggers that can cause this as well.
>> (Also please note that r1092510 is actually the correct behaviour and
>> if thats causing a deadlock then it's a concern.)
>
> The point is r1092510 is not included in the current 0.10 release candidate.

Correct and one reason why it wasn't was bcos I wasn't sure about it's
consequences and nobody seems to know why the existing code was done
that way.
However that is just one code path that caused this deadlock, there
can be others and bcos of test failures we are not sure.
Perhaps I am a bit pessimistic here, but then it's always better be
safer than sorry.

>> Same can be said for QPID-3214.
>>
>> The fact remains that we do have deadlocks lying around in the code
>> and they have a better chance of happening with 0.10 !
>
> Again, why do 'they have a better chance of happening with 0.10'? I'm not
> saying it is not true, and I'm not disagreeing the current locking
> 'strategy' seems very prone to deadlocks. I would just like to see a more
> concrete demonstration that there is regression.

Unfortunately I am unable to pin point to certain commits to backup my
assertions.
That is one reason why I didn't want to hold up the release and didn't
make any of the two JIRA's as blockers.
But it's still makes me a bit uncomfortable.

Rajith

> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to