Configuration, Development and Operations Questions
How do I enable restartable mode?
In the servers section of your tc-config.xml, include the following configurations:
<servers>
<server host="host1" name="Server1">
<data-backup>path/to/my/backup/directory</data-backup>
</server>
<restartable enabled="true"/>
</servers>
If persistence of shared data is not required across restarts, set <restartable enabled> to "false".
How do I configure failover to work properly with two Terracotta servers?
Configure both servers in the
<servers> section of the Terracotta configuration file. Start the two Terracotta server instances that use that configuration file, one server assumes control of the cluster (the ACTIVE) and the second becomes the mirror (the PASSIVE). For more information, see
Configuring a Terracotta Cluster for High Availability.
How do I know that my application has started up with a Terracotta client and is sharing data?
The Terracotta Management Console (TMC) displays cluster topology by listing Terracotta server groups and connected client nodes in a navigation tree. For more information, see the Terracotta Management Console User Guide.
In addition, check standard output for messages that the Terracotta client has started up without errors. Terracotta clients also log messages to a file specified in the <clients> section of the tc-config file.
Is there a maximum number of objects that can be held by one Terracotta server instance?
The number of objects that can be held by a Terracotta server instance is two billion, a limit imposed by the design of Java collections. It is unlikely that a Terracotta cluster will need to approach even 50 percent of that maximum. However, if it does, other issues may arise that require the rearchitecting of how application data is handled in the cluster.
How many Terracotta clients (L1s) can connect to the Terracotta Server Array (L2s) in a cluster?
While the number of L1s that can exist in a Terracotta cluster is theoretically unbounded (and cannot be configured), effectively planning for resource limitations and the size of the shared data set should yield an optimum number. Typically, the most important factors that will impact that number are the requirements for performance and availability. Typical questions when sizing a cluster:
What is the desired transactions-per-second?
What are the failover scenarios?
How fast and reliable is the network and hardware? How much memory and disk space will each machine have?
How much shared data is going to be stored in the cluster? How much of that data should be on the L1s? Will BigMemory be used?
How many stripes (active Terracotta servers) does the cluster have?
How much load will there be on the L1s? On the L2s?
The most important method for determining the optimum size of a cluster is to test various cluster configurations under load and observe how well each setup meets overall requirements.
What's the best way for my application to listen to Terracotta cluster events such as lost application nodes?
If you are using Ehcache, use the cluster-events Ehcache API.
How can my application check that the Terracotta process is alive at runtime?
Your application can check to see if the system property tc.active is true. For example, the following line of code would return true if Terracotta is active at the time it is run:
Boolean.getBoolean("tc.active");
How do I confirm that my Terracotta servers are up and running correctly?
Here are some ways to confirm that your Terracotta servers are running:
Connect to the servers using the Terracotta Management Console (see the
Terracotta Management Console User Guide).
Check the standard output messages to see that each server started without errors.
Check each server's logs to see that each server started without errors. The location of server logs is specified in
tc-config.xml.
Use the Terracotta script
server-stat.sh or
server-stat.bat to generate a short status report on one or more Terracotta servers.
Use a tool such as
wget to access the /config or /version servlet. For example, for a server running on localhost and port 9889, use the following wget command to connect to the version servlet:
[PROMPT] wget http://localhost:9889/version
Are there ways I can monitor the cluster that don't involve using the Terracotta Management Console?
You can use the REST API (see the Terracotta REST API Developer Guide) or the monitoring feature provided by WAN Replication Service (see the WAN Replication User Guide).
Why is it a bad idea to change shared data in a shutdown hook?
If a node attempts to change shared data while exiting, and the shutdown thread blocks, the node may hang and be dropped from the cluster, failing to exit as planned. The thread may block for any number of reasons, such as the failure to obtain a lock. A better alternative is to use the cluster events API to have a second node (one that is not exiting) execute certain code when it detects that the first node is exiting. If you are using Ehcache, use the cluster-events Ehcache API.
You can call org.terracotta.api.Terracotta.registerBeforeShutdownHook(Runnable beforeShutDownHook) to perform various cleanup tasks before the Terracotta client disconnects and shuts down.
Note that a Terracotta client is not required to release locks before shutting down. The Terracotta server will reclaim those locks, although any outstanding transactions are not committed.
Can I store collections inside collections that are stored as values in a cache?
This is not recommended unless your application logic takes careful account of how such values can be modified safely. Race conditions, undefined results, ConcurrentModificationException, and other problems can arise.