commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <>
Subject [jira] Commented: (COLLECTIONS-3) NPE: map.LRUMap.reuseMapping(
Date Sun, 01 Jul 2007 02:56:04 GMT


Henri Yandell commented on COLLECTIONS-3:

That should be:

synchronized(map) {

Playing with SoakLRUMap, not doing that gives a ConcurrentModificationException, which hasn't
been reported so far. 

Mostly I get IllegalStateExceptions when playing with SoakLRUMap and not synchronizing the
Map, however I did get one NPE still:


Line is:

            entry.before.after = entry.after;

Which, looking at the code, implies that entry.before is null. Maybe another place to put
a state check?

Maybe a state check would be worth it there too?

> NPE: map.LRUMap.reuseMapping(
> ---------------------------------------------
>                 Key: COLLECTIONS-3
>                 URL:
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Map
>    Affects Versions: 3.1
>         Environment: Operating System: Linux
> Platform: PC
>            Reporter: Otis Gospodnetic
>         Attachments: commons-collections-3.2-LRUMap-debug.jar,,
> I'm using Collections 3.1 and just found this NPE in my logs:
> java.lang.NullPointerException
>         at
>         at
>         at
> I instantiated LRUMap like this:
>   LRUMap map = new LRUMap(31);
> And from there on, I use it like I'd use any Map, putting things into
> it, and so on.  Maybe I'm not using LRUMap correctly?  My _guess_ is
> that this occurs when the Map is full, but I am not certain.
> I am wrapping the LRUMap in my own Maps as follows, but I think they're
> not the culprit:
>   LRUMap map = new LRUMap(31);
>     _userSessions = new ExpiringMap(map,
>        new TimerTTLReferenceHolder(1800000), // ttl=30min
>        300000);                              // purge frequency=5min
> The only similar thing I found is COM-1288, but it looks like that was fixed
> before 3.1 release.
> I understand the value of a self-contained unit test that demonstrates this bug,
> but it happens only occassionally on my production system, never during
> development, so I can't really come up with it :(
> My guess is that this is a boundary case, as line 272 is:
>  loop =;
> So 'loop' is most likely null, and it's null because ... not sure, maybe that
> hashIndex is wrong.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message