You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-dev@jakarta.apache.org by Scott Jarvi <sc...@hotmail.com> on 2004/06/18 21:39:50 UTC
Problem with JCS and IBM JVM (1.4.1)
Hi,
We are using JCS and our applications are deployed on Websphere 5.1, which
is using 1.4.1 of the IBM JDK. When calling the remove() method, I get the
following NullPointer:
at
org.apache.jcs.engine.memory.lru.LRUMemoryCache.removeNode(LRUMemoryCache.java:385)
at
org.apache.jcs.engine.memory.lru.LRUMemoryCache.remove(LRUMemoryCache.java:240)
at
org.apache.jcs.engine.control.CompositeCache.remove(CompositeCache.java:727)
at
org.apache.jcs.engine.control.CompositeCache.remove(CompositeCache.java:690)
at org.apache.jcs.access.CacheAccess.remove(CacheAccess.java:373)
I was able to track down what I *think* is a problem in the order of calls.
In LRUMemoryCache.remove(Serializable), these two lines of code (~line 292):
itr.remove();
removeNode( ( MemoryElementDescriptor )
entry.getValue() );
Same issue with line ~316.
I think these calls should be swapped. It seems that the IBM implemenation
of Iterator.remove() behaves slightly differently than Sun's. Has anyone
else experienced this problem?
Thanks,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
RE: LRUMemoryCache
Posted by Aaron Smuts <aa...@wisc.edu>.
I for one am working on a project where we are running 1.3. I'd like to
be able to use my own project. Ha!
We might be able to have a separate build for 1.4 and eventually make
this a default. Everything in the cache is pluggable by name, so it is
possible to make a new memory cache if someone can figure out where to
put the code and how to structure the build.
We really do need to move on and take advantage of the new feature in
1.4.
Aaron
> -----Original Message-----
> From: Antonio Gallardo [mailto:agallardo@agssa.net]
> Sent: Saturday, June 19, 2004 6:52 PM
> To: turbine-jcs-dev@jakarta.apache.org
> Subject: RE: LRUMemoryCache
>
> Hi Hanson:
>
> I think you are right. The LinkedMap is not suitable to our needs. My
> point was most about the compatibility for J2SDK 1.3. I know we want
to
> move to 1.4 there are a lot of advantages + other things.
Unfortunately,
> there is still a lot of people using 1.3. I think under a minor
release it
> is not fair set up the entry level to 1.4. We can do that in the next
> major release. I am newbie in JCS and I don't know the JCS roadmap.
> Perhaps I am totally OT in the above comment.
>
> Second, by pointing to commons-collections I just wanted to show there
are
> a lot of collections, maps, lists and similars that can be useful to
fill
> the gap between 1.3 and 1.4. Maybe we can find one commons-collection
> class suitable to our needs. We can only win if we there is already,
> because JCS is dependent to commons-collections.
>
> Thanks for the time to analyze both collections.
>
> Best Regards,
>
> Antonio Gallardo.
>
> Hanson Char dijo:
> >>Perhaps we need to stay compatible with J2SDK 1.3.
> >>A lot of projects on the ASF stick to this requirement.
> >>BTW, in jakarta commons collections we have:
> >>http://jakarta.apache.org/commons/collections/apidocs-
> COLLECTIONS_3_0/org/a
> > pache/commons/collections/map/LinkedMap.html
> >>I am not sure if this can be used and if this works in 1.3.
> >
> > Unfortunately, the LinkedMap in jakarta-commons collections has the
> > limitation that (extracted from the javadoc):
> >
> > "In this implementation order is maintained by original
insertion."
> >
> > where as the LinkedHashMap in JDK1.4+:
> >
> > "A special constructor is provided to create a linked hash map
whose
> > order of iteration is the order in which its entries were last
accessed,
> > from least-recently accessed to most-recently (access-order)."
> >
> > Also, from the javadoc of LinkedMap:
> >
> > "This implementation improves on the JDK1.4 LinkedHashMap by
adding
> > the
> > MapIterator functionality, additional convenience methods and
allowing
> > bidirectional iteration."
> >
> > but it doesn't mention about the loss of the "LRU" functionality
from
> the
> > JDK1.4 LinkedHashMap!
> >
> > It seems to be an easy task to provide a JDK1.3 compatible version
of
> > LinkedHashMap based on the JDK1.4 implementation. Or does it need
to be
> > an
> > absolute clean-room re-implementation of the JDK1.4 LinkedHashMap
> > functionalities in order to avoid any licensing issue ?
> >
> > Hanson
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-jcs-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
RE: LRUMemoryCache
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Hanson:
I think you are right. The LinkedMap is not suitable to our needs. My
point was most about the compatibility for J2SDK 1.3. I know we want to
move to 1.4 there are a lot of advantages + other things. Unfortunately,
there is still a lot of people using 1.3. I think under a minor release it
is not fair set up the entry level to 1.4. We can do that in the next
major release. I am newbie in JCS and I don't know the JCS roadmap.
Perhaps I am totally OT in the above comment.
Second, by pointing to commons-collections I just wanted to show there are
a lot of collections, maps, lists and similars that can be useful to fill
the gap between 1.3 and 1.4. Maybe we can find one commons-collection
class suitable to our needs. We can only win if we there is already,
because JCS is dependent to commons-collections.
Thanks for the time to analyze both collections.
Best Regards,
Antonio Gallardo.
Hanson Char dijo:
>>Perhaps we need to stay compatible with J2SDK 1.3.
>>A lot of projects on the ASF stick to this requirement.
>>BTW, in jakarta commons collections we have:
>>http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_0/org/a
> pache/commons/collections/map/LinkedMap.html
>>I am not sure if this can be used and if this works in 1.3.
>
> Unfortunately, the LinkedMap in jakarta-commons collections has the
> limitation that (extracted from the javadoc):
>
> "In this implementation order is maintained by original insertion."
>
> where as the LinkedHashMap in JDK1.4+:
>
> "A special constructor is provided to create a linked hash map whose
> order of iteration is the order in which its entries were last accessed,
> from least-recently accessed to most-recently (access-order)."
>
> Also, from the javadoc of LinkedMap:
>
> "This implementation improves on the JDK1.4 LinkedHashMap by adding
> the
> MapIterator functionality, additional convenience methods and allowing
> bidirectional iteration."
>
> but it doesn't mention about the loss of the "LRU" functionality from the
> JDK1.4 LinkedHashMap!
>
> It seems to be an easy task to provide a JDK1.3 compatible version of
> LinkedHashMap based on the JDK1.4 implementation. Or does it need to be
> an
> absolute clean-room re-implementation of the JDK1.4 LinkedHashMap
> functionalities in order to avoid any licensing issue ?
>
> Hanson
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
RE: LRUMemoryCache
Posted by Hanson Char <ha...@yahoo.com>.
>Perhaps we need to stay compatible with J2SDK 1.3.
>A lot of projects on the ASF stick to this requirement.
>BTW, in jakarta commons collections we have:
>http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_0/org/a
pache/commons/collections/map/LinkedMap.html
>I am not sure if this can be used and if this works in 1.3.
Unfortunately, the LinkedMap in jakarta-commons collections has the
limitation that (extracted from the javadoc):
"In this implementation order is maintained by original insertion."
where as the LinkedHashMap in JDK1.4+:
"A special constructor is provided to create a linked hash map whose
order of iteration is the order in which its entries were last accessed,
from least-recently accessed to most-recently (access-order)."
Also, from the javadoc of LinkedMap:
"This implementation improves on the JDK1.4 LinkedHashMap by adding the
MapIterator functionality, additional convenience methods and allowing
bidirectional iteration."
but it doesn't mention about the loss of the "LRU" functionality from the
JDK1.4 LinkedHashMap!
It seems to be an easy task to provide a JDK1.3 compatible version of
LinkedHashMap based on the JDK1.4 implementation. Or does it need to be an
absolute clean-room re-implementation of the JDK1.4 LinkedHashMap
functionalities in order to avoid any licensing issue ?
Hanson
Re: LRUMemoryCache
Posted by Antonio Gallardo <ag...@agssa.net>.
Hanson Char dijo:
> In light of Item 30 of Effective Java, ever thought of replacing the
> internal home-grown implementation of LRUMemoryCache with something like
> the
> java.util.LinkedHashMap provided in JDK1.4+, which, as documented in the
> javadoc:
>
> "This kind of map is well-suited to building LRU caches"
>
> I imagine (ie without proof) the JDK implementation would give the benefit
> of a standard, expert implementation with better performance and
> correctness (synchronization).
Perhaps we need to stay compatible with J2SDK 1.3. A lot of projects on
the ASF stick to this requirement.
BTW, in jakarta commons collections we have:
http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_0/org/apache/commons/collections/map/LinkedMap.html
I am not sure if this can be used and if this works in 1.3.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
RE: Problem with JCS and IBM JVM (1.4.1)
Posted by Aaron Smuts <aa...@wisc.edu>.
I'll look into it. I'm currently working on a project using websphere
4.? Jdk1.3.? on z/os and it seems to work fine. Let me think about it.
Have you tried to modify it and run your patched version?
Aaron
> -----Original Message-----
> From: Scott Jarvi [mailto:scott_jarvi@hotmail.com]
> Sent: Friday, June 18, 2004 2:40 PM
> To: turbine-jcs-dev@jakarta.apache.org
> Subject: Problem with JCS and IBM JVM (1.4.1)
>
> Hi,
>
> We are using JCS and our applications are deployed on Websphere 5.1,
which
> is using 1.4.1 of the IBM JDK. When calling the remove() method, I
get
> the
> following NullPointer:
>
> at
>
org.apache.jcs.engine.memory.lru.LRUMemoryCache.removeNode(LRUMemoryCach
e.
> java:385)
> at
>
org.apache.jcs.engine.memory.lru.LRUMemoryCache.remove(LRUMemoryCache.ja
va
> :240)
> at
>
org.apache.jcs.engine.control.CompositeCache.remove(CompositeCache.java:
72
> 7)
> at
>
org.apache.jcs.engine.control.CompositeCache.remove(CompositeCache.java:
69
> 0)
> at
org.apache.jcs.access.CacheAccess.remove(CacheAccess.java:373)
>
>
> I was able to track down what I *think* is a problem in the order of
> calls.
> In LRUMemoryCache.remove(Serializable), these two lines of code (~line
> 292):
>
> itr.remove();
>
> removeNode( ( MemoryElementDescriptor )
> entry.getValue() );
>
> Same issue with line ~316.
>
> I think these calls should be swapped. It seems that the IBM
> implemenation
> of Iterator.remove() behaves slightly differently than Sun's. Has
anyone
> else experienced this problem?
>
> Thanks,
> Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-jcs-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
LRUMemoryCache
Posted by Hanson Char <ha...@yahoo.com>.
In light of Item 30 of Effective Java, ever thought of replacing the
internal home-grown implementation of LRUMemoryCache with something like the
java.util.LinkedHashMap provided in JDK1.4+, which, as documented in the
javadoc:
"This kind of map is well-suited to building LRU caches"
I imagine (ie without proof) the JDK implementation would give the benefit
of a standard, expert implementation with better performance and correctness
(synchronization).
Hanson