Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Yeah Web-sessions have been supported for a while. So you can use it with 3.1.1. See http://www.terracotta.org/confluence/display/docs/Terracotta+Documentation+Archive

Of course upgrading to 3.3. means getting the latest and greatest...

Wrt the 3.1-> 3.3 upgrade, I believe there are no guarantees of backward compatibility across major versions. So the safest thing to do would be to start with a fresh Data store and restart processes.

Have you looked at tuning diskSpoolBufferSizeMB

diskSpoolBufferSizeMB: This is the size to allocate the DiskStore for a spool buffer. Writes are made to this area and then asynchronously written to disk. The default size is 30MB. Each spool buffer is used only by its cache. If you get OutOfMemory errors consider lowering this value. To improve DiskStore performance consider increasing it. Trace level logging in the DiskStore will show if put back ups are occurring.

POJO clustering is the ability to share any arbitrary Java object graph - e.g. if your domain model involves a Hashmap that contains Vectors which contain ArrayLists etc. you can get replication/persistence for that graph via DSO (Distributed Shared Objects).

EHcache on the other had is a classic cache - with a well defined API. Just like DSO you get "correct" replication/persistence for the contents of the cache. Yes, you could take the domain model and dump it into an EHcache and achieve replication amongst JVMs/ Persistence like you did with DSO. However, the API supports several "cache" features like Event Listeners, Eviction, Bulk Loading etc... See ehcache.org and terracotta.org (for DSO) for the capabilities of each.

If customSessionManager has no field named chatApiSessions - then that could be the source of the issue. The root is the fully qualified name of the reference that you wish to get replicated.

Your snippets are rather confusing - in that the snippet for CustomSessionManager that is inline has no field named chatApiSessions, but the examples you have attached do have the field?

Assuming you are on a recent version of Terracotta, those properties should help put in some grace period (300s = 5 min) during which time a disconnected client would be allowed to connect back into the cluster. Are you sure all services including TC server were restarted after this config change - the config read in is printed out in the tc-server logs, when it starts up.

JIRA says:
"This assertion shouldn't happen in TC_3.2.1_2. You should be ok with that revision."

What you put into the cache are Elements - see http://ehcache.org/apidocs/net/sf/ehcache/Element.html

The Element constructor takes a java.lang.Object as key, and a java.lang.Object as value - so of course you can put in a Map or something like that as the value.

Yes, you can deploy Ehcache unclustered or distributed with a Terracotta server, if I understood your latter question correctly. See http://www.terracotta.org/ehcache/

Sorry its not too clear - what your issue is.
What I gather is that you have 2 Tomcats with Ehcache-RMI based replication turned on and you actually notice that caches are getting replicated... And you are wondering why since TTL=0?

TTL=0 means the cache element lives for eternity - so cache elements never expire and are therefore replicated. See http://ehcache.org/documentation/configuration.html

Looks like a dupe of http://forums.terracotta.org/forums/posts/list/3923.page

There are many options - simplest I suppose you could keep 2 ehcache.xml (ehcache_withTC.xml or ehcache_noTC.xml) files and depending on your environment create a symlink called ehcache.xml to the right one. And have your code bootstrap via ehcache.xml - or use a java-system.property to determine which ehcache.xml to load...

You can add an auto-synchronized=true attribute to the auto-lock XML element, if you do not wish to modify source code. I wouldn't carry the "transparency" analogue too far - since it really means that if you have a correct app (correct from a multi-threaded perspective) then you'll enjoy the benefits of transparency when you scale out to multiple-JVMs.

Also if you are sharing between a web app and a stand-alone app you'd need to define an app-group (Look for /tc:tc-config/application/dso/app-groups at http://open.terracottatech.com/confluence/display/docs32/Configuration+Guide+and+Reference#ConfigurationGuideandReference-ApplicationConfigurationSection).

hope this helps.

no. The bind function associates a local address with a socket. So I am unsure what is meant by binding to 2 network addresses?

You can specify - 0.0.0.0, which is INADDR_ANY, which means bind to *ANY* (not *ALL*) interface/network address.

Well - if some user related data is only needed in the sub-application, then you could presumably leave it in session and use Terracotta for Sessions.

For the rest you can factor it out into an Ehcache (Express) and share that. Leaving one large chunk of UserData should be fine - what is large btw?

Hmm - sorry the question seems a bit convoluted.
Terracotta can work with/without an application server. If your application is deployed to a container such as Glassfish - then yes, you'd need the Module that provides the Glassfish integration glue - to then get HTTPSessions, H2LC or whatever replicated via Terracotta across instances.

what does 'depth' and 'parent' mean

Depth is the depth of the object graph - I believe you see 500, since that is the default 'fault-count' - i.e. if you miss a reference and it needs to be looked up on the server, the current DSO implementation will "fault-in" that missing reference + 'fault-count' number of references in its vicinity. Parent I reckon is the object that references the object in question. Would need a lot more detail to be able to specifically say what was going on, which resulted in a 30s wait to retrieve a particular ObjectId. I'd say if possible move to the latest TC version (3.2.1).

Yeah Standby will come up and re-synch its state from the Active - once it finishes synchronizing, then it comes into a PASSIVE-INITIALIZED state and is now part of the cluster as Passive.