Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi JensN

Based on your results, there obviously seem to be some discrepancies as far as RadarGun utilizing the latest version of Ehcache. Someone will have to investigate this further and will post a response here soon.

Thanks for pointing this out.

In that case, the elements over TTL will be evicted only if they are accessed on the L1. MaxElementsOnDisk=0 essentially means the cache has unlimited capacity.

The way to manage caches is:

1. To manage stale data - set TTL and TTI if there is a app/business reason to not access an element beyond a certain lifetime. The cache guarantees not to return an element if it is expired based on Time and evicts it from the cache in-line - but only if that element is actually accessed on the L1 by the app.

2. To manage cache sizes - set MaxElementsOnDisk based on the memory/disk capacity available on the L2 array. Once MaxElementsOnDisk is reached on a certain cache, least used elements over MaxElementsOnDisk get evicted from the L2 provided they are also expired based on TTL/TTI.

In other words, if your cache has unlimited MaxElementsOnDisk, you are saying there is unlimited capacity on the L2 and elements are never evicted on the L2 based on size. Only expired elements accessed on L1 will get evicted because they are stale (as per 1).

Another recommendation would be to set MaxElementsInMemory to a non-zero number even if it is small. It will help if your application has any sort of hot sets and locality. Set the MaxElementsInMemory such that sum of MaxElementsInMemory in all caches can fit on the L1 heap with some headroom.

Hello

It depends on the scalability, data volumes and availability requirements as well as specific features and support.

You can read more about Enterprise Ehcache here: http://www.terracotta.org/ehcache/

Please contact sales [at] terracottatech.com for licensing related questions or for differences between open source projects and enterprise products.

Can you please elaborate? I am not clear on what you mean by cluster name.

What version of Terracotta are you working with? What is the MaxElementsOnDisk set to?

Since there is a typo in Chris's response, I want to further his point: There are no CPU restrictions imposed in Open Source Terracotta. The more CPUs/cores available, the more it able to utilize and it is designed to be highly concurrent to utilize them really well.

BTW, with respect to Ehcache API, 3.4 is backward compatible and there are enough improvements/features in 3.4 to warrant an upgrade from 3.3. I would recommend upgrading the existing projects on 3.3 to 3.4 as son as your timeline would permit.

This can possibly happen with the open source disk store if the java process is not shut down cleanly.

You will not face this issue with Enterprise Ehcache with Terracotta as the disk persistence is transactional.

Can you share the entire stack trace please?

I will let someone who knows more about the RMI implementation answer your specific question.

I do want to point out though that you can start with using the open source Terracotta Server and it is as simple, if not simpler, to enable in the ehcache config without needing any code changes:

1. Start the Terracotta Server on host "someserver"

and

2. Enable the Terracotta clustering on any cache in the config:

<ehcache>
<terracottaConfigurl="someserver:9510"/>

<cache name="com.company.domain.UserCache"
maxElementsInMemory="10000"
timeToLiveSeconds="3000”>
<terracotta />
</cache>
</ehcache>

Is there a partcular feature in 2.5.0-SNAPSHOT that you are wanting to use?

Enterprise Ehcache with BigMemory will definitely help you in this instance. My guess is that with BigMemory you will probably end up needing a lot less than even 4GB as all keys and values can be stored on BigMemory instead of the Java Heap and hence do not need to go through the Java GC leading to much smaller GC pauses and most likely no OOMEs.

You can download the latest version of BigMemory here: http://www.terracotta.org/dl/download-bigmemory and the documentation for BigMemory is available here: http://ehcache.org/documentation/offheap_store.html

The following section of the documentation explains the usage of the license file:
Using a License File

In this instance, you can simply place the license file in WEB-INF/classes or specify the location explicitly by passing the following system property on the Weblogic instance:

-Dcom.tc.productkey.path=/path/to/terracotta-license.key

Hi August

Terracotta version 3.4 introduced some new features including BigMemory which also involved the change in the license.

I would recommend to continue using your 3.3 license with that version and use the 3.4 license when you upgrade to 3.4.

Any other particular reason to use the 3.4 license with 3.3?

For ease of deployment, you can package the license along with the ehcache and terracotta jars on the classpath and for the Terracotta Server it can stay in the root on the Terracotta installation.

For minimal downtime upgrade or specific backward compatibility questions you can send a query to Terracotta Support through the support channels or send me a PM.

Have you tried the Terracotta clustering instead of RMI?