Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Several reasons:

Basically in your restart sequence, if you start the clients first adn then the server, the server upon restart has the old client-ids in its persistent store. It will wait for <client-reconnect-window> time to allow them to reconnect.

So in your case, perhaps you restarted the server, but left old clients hanging around.

Also could be that l2.l1.reconnect.enabled is false (default). You could make it true and that would allow 5s for a client to reconnect. Basically if a client disconnects, then the Terracotta server needs to release resources it holds to not impact the rest of the clients. So l2.l1.reconnect.timeout.millis is the grace time allowed for the client to connect back in. Else it needs to be restarted.

Hope this helps.

Cache data in my disk always has 0 bit,I haven't got data again in my cache , can we see these cache data size in my disk?

Sorry don't understand this question.

Based on

<cache name="com.cache.model.Org" maxElementsInMemory="10"
eternal="false" timeToIdleSeconds="300" timeToLiveSeconds="600"
overflowToDisk="true" />

you are instructing the cache to spillover to disk if more than 10 elements are in memory. Are you saying that you are adding more than 10 elements and then you don't see the overflow to disk behavior?

getting notified about an eviction event is orthogonal to being able to overflow to disk.

Yes you can disable it and the version info is anonymous to only update you if there is a newer version available...

Maybe I got the requirements misunderstood - but couldn't MagicServlet pseudoCode look like:
Code:

 if (morning) {
   doChain(httpServletRequest, httpServletResponse)
 }
 else {
    httpServletResponse =  cache.get(key);
 }

Please confirm if I just got the question wrong?

Yeah Jgroups can be a bit fragile and temperamental... And once you start receiving messages such as

Jan 4 07:40:56 app3.prod.365.kink.y local7: 2010-01-04 07:40:56,736 [OOB-2,EH_CACHE,app3.prod.365.kink.y-61543] WARN - [NAKACK] app3.prod.365.kink.y-61543: dropped message from app1.prod.365.kink.y-58459 (not in xmit_table), keys are [app3.prod.365.kink.y-61543], view=[app3.prod.365.kink.y-61543|4] [app3.prod.365.kink.y-61543]

the correctness of the cluster is compromised - since you are unsure of which messages made it through and which did not.

If GC is an issue in your app - look at Xms, Xmx - choice of Collector (ParallelGC versus CMS), NewRatio etc. Terracotta.org has some useful pointers here.

Also look at replicating with Terracotta Ehcache to improve correctness - see http://www.terracotta.org/ehcache/distributed-cache/ehcache-ex

Hope this helps.

Did you get past this? The problem is that the trigger isn't firing or is it that the rollback dosen't work. Have you also tried the TerracottaStore?

I am watching the Instance Counts in the Developer Console

The Instance Counts in the Developer Console records the number of instances per object type, since Terracotta Server Start. It is *NOT* what is live currently.

If the #Live Objects are in control, then things are fine - since it is possible that org.terracotta.cache.serialization.SerializedEntry and OptimizeEvent were created but then later got Distributed-Garbage-Collected in response to removes from your application or expiration kicking in.

We are not getting any other event other than operationsDisabled(), but this event is only receieved when the active node is lost.

Yeah NodeLeft Event is not guaranteed. So when the Active L2 goes away, you get an operationsDisabled event.

What you could do now is to spawn a timer in your "operationsDisabled" Handler, which then waits for a specified interval of time to get the operationsEnabled event. If you do not get the operationsEnabled event after waiting for let's say 65s (for default that should be ok - exact duration you need to wait for depends on the l1-l2, l2-l1 and l2-l heartbeating parameters) - then you could derive that either the node in question cannot get to the Terracotta Server Array or the Terracotta Server Array tier is unavailable - and do something appropriate.

If all the Clients report that they got a Disabled but no Enabled event, then you know the TSA is either unavailable because all Terracotta Servers are dead or because no client can get to it on the network.

In the next revision - post 3.2.1 we are making some of this more transparent.

That just means that the objects in question are not yet materialized on that JVM. i.e. in your example if Node1 created an object graph and then Node 2 hasn't referenced that graph - then on the DEv Console the Cluster Graph will be Black for Node1 and Grey for Node2.

This attached document should explain the capabilities in detail. Let us know if you have any questions.
Thanks

Are you describing Standalone Ehcache or Ehcache with Terracotta based Replication.

In the former, if you make maxElementsInMemory too large, then you might OOME the Client JVM.

In the latter, you can make maxElementsInMemory very large and rely on Terracotta Virtual Memory Manager Settings to help manage your Memory Based Policy so the Client JVM does not OOME. All the Cache Data would be on the TC Server (and on Disk in persistent mode, or partially on disk in non-persistent mode). You can avoid disk on the TC server as well, by either provisioning a large heap on the Terracotta Server or via Terracotta FX (multiple Active Terracotta Servers).

We are looking into this.

Does this happen sporadically - I mean is this because the Repositories were briefly unavailable or does it always fail at the same spot, when it fails.

Terracotta 3.2.1 supports glassfish v3. Available as a Beta at http://www.terracotta.org/beta/darwin

Thanks for the snippet...