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?
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.
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.
--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
