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.
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.) 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 ! Having said that I agree with Marnie that we should not be holding up the release, as fixing these issues safely may not be possible within the next week or so. (We need to release note both these issues, if we go ahead with the release.) Regards, Rajith On Wed, Apr 20, 2011 at 9:14 AM, Gordon Sim <g...@redhat.com> wrote: > On 04/20/2011 10:36 AM, Marnie McCormack wrote: >> >> I've had a look at the details and I'd like to propose the release go >> ahead >> now, rather than be delayed any further. >> >> The reasoning is that the Java items highlighted are not strictly >> regressions (existing largely in Qpid 0.8) and more importantly the fixes >> for them, and associated issues, are likely best measured in weeks and >> 0.12 >> seems a realistic target for them. > > QPID-3216 was apparently caused by r1092510, itself a fix to QPID-3207 made > last Thursday, which isn't even on the 0-10 branch as far as I can see. That > being the case I don't think we need to consider blocking for this one > (unless QPID-3207 was considered a blocker). > That leaves QPID-3214 which was apparently caused by r985262 made on Aug 13 > 2010. As Marnie points out we didn't branch for 0.8 until Nov 7 2010, > r1032358, so this bug exists in 0.8 and is not *in itself* a regression. > > That particular deadlock looks like it may be triggered when the > cancellation of a subscription occurs. It *could* therefore be more visible > following the changes made to the c++ broker for QPID-2324, which was fixed > for 0.10 (throw 404 if client attempts to close a non-existent > subscription). > > I tend to agree with Marnie. If the fix looks like it may take some time (or > if there is any doubt or risk associated with it), it may be best to proceed > with the 0.10 release without this change. > > --------------------------------------------------------------------- > 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
