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 > >
