|
Release: 2.4 Previous Releases
Publish Date: October, 2007 |
rate-6226439-81293
| Article Rating? |
|
|
|
Admin Console Guide
What is the AdminConsole
The Terracotta AdminConsole is a graphical tool that you can use to monitor various aspects of your running system. The AdminConsole is a JMX client that communicates through the jmx-port of your Terracotta Server.
Running the AdminConsole
Windows
> %TERRACOTTA_HOME%\bin\admin.bat
Unix
> ${TERRACOTTA_HOME}/bin/admin.sh&
Using the AdminConsole
The AdminConsole maintains a set of references to Terracotta Servers that you define. If no servers are defined, a default server on localhost using the default jmx-port is created. You can define any number of server references, which are maintained across AdminConsole sessions. Create a new server reference by using the File|New server menu or by using the New server context-menu in the servers list area.
Further reading:
For more information on configuring your Terracotta server's jmx-port, see the Configuration Guide and Reference.
Connecting to a server
Once you have created a server reference you can attempt to connect to that server by selecting the server node in the navigation tree on the left side of the window. In the server panel, on the right side of the window, will be displayed the server connection information. Click the Connect button. If the server is active, after a short pause, content will appear under the server node in the server list and an indication that the server is running and its start time will appear in the server panel.
An alternate way to connect to a particular server is to bring up the context menu for that server node (usually a right-click operation) and select the Connect item. To automatically connect to server, enable the Auto-connect item on the server context menu. With server auto-connect enabled, the AdminConsole is constantly attemping to connect to the server in a a background thread, doing away with the need to explicitly connect.
Connecting to a Secured Server
The Terracotta Server can be secured for JMX access, requiring an identity and password. If the AdminConsole notices that a server is secured it will prompt for an identity and password before connecting.
Further reading:
For more information on securing your server for JMX access, see the Configuration Guide and Reference.
Clustered Terracotta Servers
To avoid a single-point-of-failure Terracotta Servers can be setup in a cluster such that there is a single active and one or more passive members. The cluster can be configured such that the members either use a shared file-system or communicate server state over the network.
Shared File system-based Clusters
In the case of a cluster based on a shared file-system, passive members go into stand-by mode until a file lock held by the active members is released, at which time one of the passives takes over as the active. There are thus two states for a SAN-based cluster member:
- started (yellow)
- active (green)
Passive members in the started state are indicated by a yellow adornment in the AdminConsole while active members are indicated by a green adornment.
Network-based Clusters
In the case of a network-based cluster, passive members go through the following stages:
- started (yellow)
- passive-uninitialized (orange)
- passive-standby (cyan)
- active (green)
The following shows a two-member cluster with the active member named primary and the single passive member, standing-by, named secondary.
Servers that are not accessible for any reason are indicated by a red adornment.
Further reading:
For more information on setting up you cluster, see Configuring a Terracotta Server Cluster.
Disconnecting from a server
Once you have connected to a running server, you can disconnect your session by clicking the Disconnect button on the server panel or by selecting the Disconnect item from the server context menu.
The AdminConsole will automatically notice a server termination and disconnect from that server.
Viewing the DSO Subsystem
Roots
Using DSO, you can specify that certain fields of your Java classes be transparently shared amongst multiple DSO-enabled applications. These shared fields in your classes are referred to as DSO roots. You can view the complete set of roots known to the server by selecting the Roots node.
In addition, each individual root is also broken out as a separate node under the Roots node. You can navigate through the root object graph and refresh the contents of the root by selecting the Refresh context menu on the root node. Simply selecting an object in the root graph will cause it's content to be refreshed.
Further reading:
For more information on roots, see the Concept and Architecture Guide
Classes
DSO allows for transparent, clustered object state synchronization. To accomplish this feature, some of your application classes will be adapted into new classes that are cluster-aware. The set of all such adapted classes known to the server are displayed in the Classes panel. The Tabular tab show all the adapted classes in a spreadsheet view, including the class name and a count of the number of instances of the class that have been created since the server started. The Tree tab shows a heirarchical, or Java package, view of the adapted classes. Finally, the TreeMap tab shows a presentation making it easy to quickly distinguish the most (and least) heavily used adapted classes. These views are a snapshots of the adapted classes known to the server. You can refresh these values by selecting the Refresh context menu on the Classes node.
Further reading:
For more information on object portability see the Concept and Architecture Guide.
Clients
When a DSO client application connects to a server being monitored by the AdminConsole, a client node is created under the Clients node.
A client is represented as a communication channel ID, a hostname, and a port. Under each client node you will find additional client-specific statistics, such as Transaction Rate. When a DSO client disconnects from a server, that client node is automatically removed from the server heirarchy.
Cache Activity
The DSO server in-memory cache can be configured to hold some maximum number of objects from client root object graphs. When the number of shared objects known to the server exceeds the cache capacity, objects that have been Least-Recently-Used (LRU) are flushed from the in-memory cache to the disk cache. When a client requires an object that has been flushed to disk, that object is faulted from disk back into the in-memory cache, and the object state is transmitted to the client. The following two statistics relate to the DSO server cache activity.
Object Flush Rate
The Object Flush Rate statistic shows a measure of how many objects are being flushed out of the client memory. These objects are available in the server if needed at a later point in time.
Object Fault Rate
The Object Fault Rate statistic shows a measure of how many objects are being faulted into the client memory from the server.
Cache Miss Rate
The Cache Miss Rate statistic shows a measure of how many objects are being faulted from the disk-cache per second, as opposed to being retrieved from the server's in-memory cache.
Object Transaction Rate
The Object Transaction Rate statistic shows a measure of how many getfield/putfield calls have been invoked on shared objects. For instance, if you have defined a root that includes an int field, setting that fields value is a single transaction.
Distributed Garbage Collection
Objects in a DSO root object graph may become unreferenced at any time. DSO occasionally garbage collects such unreferenced objects. You can view the garbage collection statistics in the Garbage collection panel. Each time a collection occurs, that information is broadcast to the AdminConsole, so there is no need to refresh. You can view the gc iteration index, the start time of the iteration, the time elapsed during the sweep, the total number of shared objects held by the server, the number of shared objects that are candidates for collection, and finally the total number of shared objects that were actually collected.
Further reading:
For more information on configuring your Terracotta server's garbage collection, refer to the Concept and Architecture Guide.
For information on forcing the server to reclaim unused shared objects, see Terracotta Tools.
Update Checker
On a bi-weekly basis the AdminConsole will check, when first started, on updates to the Terracotta platform. By default, a notice informing you that an update check is about to be performed is displayed, allowing to ignore the immediate check, acknowledge and allow the check, or to disable further checking.
Should the update check be allowed, the AdminConsole will query the OpenTerracotta website (www.terracotta.org) and report on any new updates. Should the update checker feature be disabled, it can always be re-enabled via the Help|Update Checker... menu.
Appendix
Contacting Terracotta
Contact Terracotta at the following:
Web site: http://www.terracotta.org
Online forums: http://forums.terracottatech.com/forums/
Information: info@terracottatech.com
Platform Support
See Platform Support for information on which platforms are supported by Terracotta.
See Integrations to see the status of integrations with third-party technologies.
Copyright Information
Copyright © 2005-2007
Terracotta, Inc.
All Rights Reserved
This publication (the "Documentation") and the Terracotta software which it describes (the "Software") are protected to the maximum extent permitted under applicable law, including but not limited to, the regulations set forth in Title 17 of the United States Code, and California law. This Documentation, or any parts thereof, may not be reproduced in any form, by any method, for any purpose, without the express written consent of Terracotta. Terracotta makes no warranty, either express or implied, including but not limited to any implied warranties of merchantability or fitness for a particular purpose, with respect to the Software discussed in this Documentation, and the Documentation itself (collectively, "the Materials"). The Materials are made available solely on an "as-is" basis. In no event shall Terracotta be liable to anyone for special, collateral, incidental, indirect, punitive, exemplary, or consequential damages in connection with, or arising from the purchase or use of, the Materials. Under no circumstances and regardless of the cause of action alleged, shall Terracotta's liability exceed the purchase price of the Software described herein. Terracotta reserves the right to revise and improve its Software and Documentation as it deems fit. The Documentation describes the state of the Software at the time of publication.
Trademarks
"Terracotta," the stylized "T" logo, and "Open Terracotta" are trademarks of Terracotta. All other brand names, product names, or trademarks belong to their respective holders. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All other brand names, product names, or trademarks belong to their respective holders.
Government Use
Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in FAR 12.212 (Commercial Computer Software-Restricted Rights) and DFAR 267.7202 (Rights in Technical Data and Computer Software), as applicable.
