Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

After some of our engineers looked at it - the conclusion is that there is a bug (race condition) deep in clustered SureFire - therefore some of the maven goals such as tc:test, tc:run-integration etc. are broken. So I'd suggest not using those goals. A Community JIRA with votes would bring attention to it, perhaps.

Yes those ones need to be open. Also, if you are specifying RMI URLs in your ehcache.xml - then those would need to be open as well.

With regards to the restart "message" - yes it is just warning you of the behavior.

In that when a passive goes down and is then restarted, one does not know what "Terracotta transactions" it has missed. Therefore, whatever data it has on disk is moved to the side and the Terracotta Server comes up with a "blank" state. So it is possible, that when you restarted services - you restarted the passive Server first.

If a server was the Active Co-ordinator when it went down and then you restarted that first, then you would not encounter this message.

Depends - Terracotta does support some specific scenarios in the application-maturity life-cycle that you just alluded too. e.g. adding a field/removing a field from your "shared" (and instrumented) class-types. In such a case only what is common between the new and the old version of the class gets shared.

However type changes are not supported and will lead to a class-cast exception (e.g. changing a String to an int etc.). In such a case, where there are many "incompatible" application changes, you are better off blowing away the persistent store and restarting services for now.

No such events available.

Of course you can modify the source - but anyways, wouldn't this plan be a little too heavy to be practical - since depending on the application and the initial state of the graph and the rate at which objects join the graph - there could be 1000s, Millions of objects joining the graph? - So spawning as many threads on each node as there are number of live objects in the graph would be very expensive and cause other issues.

Yes it (bumping TTL programmatically) is not going to help with already expired entries, but will help with preserving existing non-expired entries (but without any increased overhead in terms of maintaining a separate cache and additional memory needed for it).

That sounds like it will work - but the question is really around whether you are willing to pay the memory overhead with regards to maintaining an "infinite" cache and potentially impacting the run-time performance of the "regular" 10-minute TTL cache - just for the one very-low-probability event of the backend data-source becomes unavailable.

Given that under steady state you care about Data-Liveness (hence the 10 minute TTL) - I wouldn't recommend changing it. But then TTL can be changed at runtime - so what you could do is to detect that the backend data-source is unavailable and then modify the TTL of the cache to something much larger than 10 minutes - this way cache.get at least returns all the cache-values that were in the cache, at the time you modified the TTL.

Hope that helps.

I suppose you could have an ehcache.xml soft-link which then points to ehcache-clustered.xml or ehcache-standalone.xml and you can modify your build system to point to the right one based on the Environment you are in.

Cache Server Cluster fail - typically, since you have 2 TC servers, you need a double failure to lose both. That should be a rarity - but if it does happen you can use Cluster Events to catch the event and take corrective action. See http://www.terracotta.org/confluence/display/docs/Cluster+Events#ClusterEvents-HandlingnodeLeftNotReceived

This behavior of reacting to complete Terracotta Sever Cluster outage is also being revisited up as a product feature in an upcoming release, to make it even easier.

Yes you can - when a TC server comes up with a "dirty" Database, it moves it aside and restarts with a fresh data-store, which it may then synchronize via the current Active.
It just keeps a backup in case, that behavior was erroneous and you actually want to restore the state to what the "dirty" database was. So yes, you could delete those.

These tc.properties help you customize the re-start behavior:
- dirtydb.l2.nha.autoRestart = true, autoDelete - Delete old database if any automatically, during passive L2 startup
# dirtydb.rolling - Retain latest rolling number of old databases in the backup directory. If 0, all old db retained.
# autoRestart - Automatically restart L2 when it goes down (on few cases only. like zap node errors, dirty database startup problems)

Horizontal scalability would mean that you can simply add more application JVMs and/or Terracotta Server JVMs on commodity boxes and the application responds in that you get more scalability (measured as TPS). This typically involves load-balancing and clustering technologies such as Terracotta.

Vertical Scalability would mean that you scale up a given resource by investing in a more powerful machine and software footprint. e.g. moving from a 4 core machine to a 16 core machine or upgrading RAM from 8G to 64G to run your RDBMS.

Hope that helps.

Code:

 <field-name>webapplication1.Page1.buffer</field-name>
  <field-name>HelloClusteredWorld.buffer</field-name>

If these 2 are the same type and you want them to be shared - then you can always specify a root-name. For an example, see: http://www.terracotta.org/confluence/display/docs/Configuration+Guide+and+Reference#ConfigurationGuideandReference-roots

Also in your case, since the classloaders involved are different - a "simple .java" and a Web Application, you'd need to use App-Groups as well - search for /tc:tc-config/application/dso/app-groups at http://www.terracotta.org/confluence/display/docs/Configuration+Guide+and+Reference

3.2.1 Should be within the next 24 hours now :-)
I believe a permission issue on S3 was fixed over the weekend.

Make sure that you remove the old boot-jar and regenerate the boot-jar. My "guess" is that this might be at the issue.

kill -3 <java-pid>

Do you prefer the JDBCDataStore - have you tried the terracottaJobStore. Let us know..
Thanks