Questions about strong vs weak reference and garbage collection

[smalone]

Hello,

I just started at a new company that uses Infinispan, and I have a few questions pertaining to garbage collection:

1. Does Infinispan use strong or weak references for each cache?

2. Does setting the eviction algorithm to None turn off garbage collection for that cache?

3. Is it possible to prevent a cache from being garbage collected (until invalidated) even if entries do not have a direct reference?

Our production setup:

Java: Java 7

Server: Tomcat 7

Infinispan: 5.2

Thanks in advance for any responses.

[sannegrinovero]

Hi,

1. Does Infinispan use strong or weak references for each cache?

Only strong references.

2. Does setting the eviction algorithm to None turn off garbage collection for that cache?

Not sure what you mean by garbage collection; if no eviction is configured, entries will reliably stay where they are. It's not designed to be used only as a cache: in theory it could be used as a database, although that's not common yet and more experimental.

3. Is it possible to prevent a cache from being garbage collected (until invalidated) even if entries do not have a direct reference?

Yes that's the only way it works (as explained in previous answers)

Infinispan: 5.2

Infinispan 5.3 is much better and an easy upgrade: we won't support 5.2 any longer..

[smalone]

Hey Sanne,

Thanks for the response. I asked about the garbage collection, because some caching systems use weak references for their cache. They only have a strong reference once the entry in the cache has been referenced again. This means that once garbage collections makes its rounds, the weak references are removed.

I'll definitely pass the word up the chain about upgrading.

Thanks!

[darrellburgan]

Sanne Grinovero wrote:

Infinispan 5.3 is much better and an easy upgrade: we won't support 5.2 any longer..

Hi Sanne, when you say it is much better, what do you really mean? More stable, better features, critical bugs fixed .... ? I've read the release notes and there's a lot there, but I don't know how to come up with an overall value judgment for the release based on the release notes.

Also, we are using JBoss EAP 6.0.1 commercial for our newer architecture, and our older architecture uses Tomcat. They do share a cache between them. For the new architecture, we're relying on the Infinispan provided by JBoss, version 5.1.8.Final-redhat-1. For the old, we're using the open source Infinispan 5.2.1. They are sharing one distributed cache between them, across these two versions. If we were to upgrade the old architecture's Infinispan to 5.3.x, would it remain binary compatible with the 5.1.8.Final-redhat-1 that JBoss EAP uses? If we need to pose that question to Red Hat support instead, please feel free to say so.  :-)

Thanks!

Darrell

[darrellburgan]

Sanne Grinovero wrote:

1. Does Infinispan use strong or weak references for each cache?

Only strong references.

By the way, this is big surprise to me. For an invalidation cache, I really thought Infinispan would prefer weak references, since it gives the gc more breathing space. I can see why strong references would be desirable for replication and distribution caches. Was it a design decision just to use strong references across all varieties of cache, or is there a more subtle reason why invalidation caches need strong references?  (Just curious).

Thanks for the help!

Darrell

[smalone]

Hey Sanne,

I took your responses and reviewed our cache statistics. There are still some questions I have.

Here is what I observed for one of our caches in a 12 hour period with the eviction method set to LIRS:

Table size: ~1900 rows

Cache Size: ~1200 entries

maxEntries: 5,000

Total hits: ~23,000,000

Total misses: ~46,000

Total evictions: ~45,000

Now when I increased the maxEntries to 10,000 for the same amount of time, this is what I observed:

Table size: ~1900 rows

Cache Size: ~1200 entries

maxEntries: 10,000

Total hits: ~33,000,000

Total misses: ~1388

Total evictions: 0

The lines to note are the total evictions. The table size is relatively small. I am unsure why 5,000 as a maxEntry size for only 2,000 rows has so many evictions because they are all reads; no writes. Based on the documentation, evictions do not take into account memory pressue on the JVM. If that is so, why would there be so many evictions?

Thanks again,

Sean