CDV ❯ Document issue regarding to TerracottaToolkit and ClusteringToolkitExtension
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
Documentation
-
-
-
Reporter: lima
-
November 11, 2011
-
0
-
Watchers: 2
-
July 27, 2012
-
January 06, 2012
Description
Toolkit doc has TerracottaToolkit, but the class cannot be found in toolkit jar. In fact the class cannot be found in any jar delivered with TC.
So there’s no obvious way to unregier any clustered objects returned from ClusteringToolkit.
Did a quick search in class files, only found the unregisterXXX methods declared in ClusteringToolkitExtension, which is an interface. Don’t see any class that implemented the methods.
So the issues are:
- document is wrong about TerracottaToolkit
- there’s no doc about how to get a ClusteringToolkitExtension instance, so can access the unregisterXXX methods.
Comments
ilevy 2012-01-06
ilevy 2012-01-06
The following section will appear in the Toolkit usage documentation (http://terracotta.org/documentation/terracotta-toolkit/toolkit-usage) in its next iteration, due out shortly:
Destroying Clustered Terracotta Toolkit Objects
You can use the unregister methods available in the interface `org.terracotta.api.ClusteringToolkitExtension` to destroy clustered Toolkit objects. The following example shows how to unregister a clustered Map:
TerracottaClient client = new TerracottaClient("localhost:9510");
ClusteringToolkit toolkit = client.getToolkit();
Map map = toolkit.getMap("myMap");
ClusteringToolkitExtension toolkitExtension = (ClusteringToolkitExtension) toolkit; // The instance must be cast to ClusteringToolkitExtension.
toolkitExtension.unregisterMap("myMap"); // The Terracotta cluster no longer has knowledge of myMap.
Do not attempt to continue using clustered Toolkit objects that have been unregistered. Doing so can lead to unpredictable results.
Certain classes that are not available in the Toolkit runtime JAR (and which are not needed for using the Toolkit) nevertheless are in the Javadoc (that is the doc that Li Ma is referring to).
We’ll add a secondary task to limit the Javadoc to the classes in the runtime JAR.