You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2005/10/08 15:35:13 UTC

[collections] Bug Fix Help wanted! (so we can release v3.2)

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections] Bug Fix Help wanted! (so we can release v3.2)

Posted by sebb <se...@gmail.com>.
[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 <ph...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections] Bug Fix Help wanted! (so we can release v3.2)

Posted by Phil Steitz <ph...@gmail.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections] Bug Fix Help wanted! (so we can release v3.2)

Posted by Phil Steitz <ph...@gmail.com>.
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 <sc...@btopenworld.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections] Bug Fix Help wanted! (so we can release v3.2)

Posted by Stephen Colebourne <sc...@btopenworld.com>.
>>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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


RE: [collections] Bug Fix Help wanted! (so we can release v3.2)

Posted by Arnaud HERITIER <ah...@gmail.com>.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections] Bug Fix Help wanted! (so we can release v3.2)

Posted by Stephen Colebourne <sc...@btopenworld.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections] Bug Fix Help wanted! (so we can release v3.2)

Posted by Brett Porter <br...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org