Re: [collections] Bug Fix Help wanted! (so we can release v3.2)
[Not relevant here, but might be an idea to make private boolean scanUntilRemovable; final to avoid any untoward behaviour.] Not sure if this is relevant, but the super-class AbstractHashedMap is not thread-safe. For example, the instance variable size is not protected against multiple threads: the field size is not volatile, and it is not accessed via synchronised methods. Might be an idea to document which classes are intended to be thread-safe? Also might be worth running the code against FindBugs in case that gives more clues. I can perhaps do that tonight. HTH. Seb On 10/10/05, Phil Steitz [EMAIL PROTECTED] wrote: Still nothing meaningful to report, other than that it is easy to get the NPE when access to put / get is not synchronized. I do not see how this could happen, though when access is synchronized and the keys are immutable. Will keep trying. Stephen - can you pls attach the debug source to the ticket? thx Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Bug Fix Help wanted! (so we can release v3.2)
Still nothing meaningful to report, other than that it is easy to get the NPE when access to put / get is not synchronized. I do not see how this could happen, though when access is synchronized and the keys are immutable. Will keep trying. Stephen - can you pls attach the debug source to the ticket? thx Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Bug Fix Help wanted! (so we can release v3.2)
Stephen Colebourne wrote: If not, then I will just release 3.2 with extra debugging and warning notes, which is not good for our reputation. Is it isolated to changes in LRUMap? I mean, can those reproducing it rollback to 3.1's (or near enough) LRUMap and it goes away? If so, that could be a way to get to 3.2. I don't know about releasing such a version with debugging and a known regression. perhaps labelled 3.2-beta with the extra debugging info to try and track it down? Just my 2c, I don't have time to test it right now. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Bug Fix Help wanted! (so we can release v3.2)
Brett Porter wrote: Stephen Colebourne wrote: If not, then I will just release 3.2 with extra debugging and warning notes, which is not good for our reputation. Is it isolated to changes in LRUMap? I mean, can those reproducing it rollback to 3.1's (or near enough) LRUMap and it goes away? If so, that could be a way to get to 3.2. There is no evidence that we introduced this since 3.1. I believe it has been there since class creation in 3.0 (or alternatively that there is in fact no problem at all) I don't know about releasing such a version with debugging and a known regression. perhaps labelled 3.2-beta with the extra debugging info to try and track it down? I've uploaded a jar to bugzilla with debugging. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Bug Fix Help wanted! (so we can release v3.2)
There is no evidence that we introduced this since 3.1. I believe it has been there since class creation in 3.0 (or alternatively that there is in fact no problem at all) I don't know about releasing such a version with debugging and a known regression. perhaps labelled 3.2-beta with the extra debugging info to try and track it down? I've uploaded a jar to bugzilla with debugging. Hi Stephen It could be easier for maven users to test it if you add a SNAPSHOT in the repository : /www/cvs.apache.org/repository Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Bug Fix Help wanted! (so we can release v3.2)
I've uploaded a jar to bugzilla with debugging. Arnaud HERITIER wrote: It could be easier for maven users to test it if you add a SNAPSHOT in the repository : /www/cvs.apache.org/repository Maybe, but as a debugging version, I really want to avoid that if possible. There's always the danger of something incomplete getting 'into the wild'. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Bug Fix Help wanted! (so we can release v3.2)
I have also spent quite a few hours looking at this and I agree that from the reports it looks like a real (and bad) bug. I will look at it again this evening using your debugging jar - that's the kind of thing I was doing before when I looked at it before. I was also working on improving the documentation in the code, which is a bit inscrutable. I would be -0 for release as is. Will post more after digging in again. Phil On 10/8/05, Stephen Colebourne [EMAIL PROTECTED] wrote: Hi all, [collections] v3.2 has many many bug fixes and enhancements over 3.1 and should have been released ages ago. However one bug is holding everything up, and I can't sort it. http://issues.apache.org/bugzilla/show_bug.cgi?id=32573 It concerns LRUMap, where use in production seems to cause random failure. This can be reproduced using mutable keys, or incorrect serialization, however the users all claim that there is some other problem. We now have about 5-6 people reporting this, so I tend to favour it being a real problem. Anyway, I've looked and failed to find a solution. Does anyone else have any time to look into this??? If not, then I will just release 3.2 with extra debugging and warning notes, which is not good for our reputation. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
