From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com]
Sent: Thursday, April 21, 2011 4:44 AM
To: dev@qpid.apache.org
Subject: Re: [VOTE] Release 0.10
All,
I think this [VOTE} thread could be closed. The question is
does anyone wish to change their vote in the light of the
discussions over the 7 days it has been open ?
We should decide today if we're proceeding or not, as its all
getting a little confusing ;-)
If people are uncomfortable with the muddying of the [VOTE]
thread with discussions, we could re-start but I don't think
we 'need' to from a process point of view.
Thanks & Regards,
Marnie
On Wed, Apr 20, 2011 at 4:17 PM, Rajith Attapattu
<rajit...@gmail.com>wrote:
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
