Release: 2.6-stable4 Previous Releases
Publish Date: May, 2008

rate-9764991-70089

Article Rating?

1

2

3

4

5

Release Notes 2.6

Changes in 2.6

Changes in 2.6

Bug Fixes

View Jira

New Features

CDV-314
Snapshot Statistics Tool

CDV-498
Server detection of Rogue Clients. If the server detects a misbehaving client, it can terminate that client's connection to the cluster

CDV-579
Support for Apache Tomcat 6.0.16

CDV-56
Healthchecker and Heartbeat. Client to Server, Server to Client, and Server-to-Server in Network Active-Passive setup

CDV-313
Support for sharing of reflection objects

CDV-112
New system property for setting system classloader name to allow standalone to web app dso

Additional Improvements

Added the ability to thread dump on assertion and exceptions
Performance Improvements in Networked Active Passive configuration
Improved ConcurrentHashMap Performance
Faulting outside lock scope in maps
Greedy lock leasing to reduce ping-ponging
Maintaining compressed strings across Terracotta Clients to reduce memory footprint
String interning across JVMs
Transaction folding

Known Issues

CDV-538 Redeployed web applications will almost certainly run into ClassCastExceptions for shared application-level objects.

CDV-586 The Windows scripts convert directory paths to 8.3 form to avoid trouble with spaces. The command that does the conversion doesn't work with a path like C:\Program Files\Java\jdk1.6.0, but does with C:\Program Files\Java\jdk1.6.0_04.
- Workaround: Install JDK to a directory path without a space, or install to directory path with appended JDK minor version.

CDV-637 In configurator java.lang.UnsupportedClassVersionError is thrown when using BEA WebLogic 8.1.
- Workaround: Use a later version of BEA Weblogic.

CDV-255 Default java security policy under Websphere AS doesn't work correctly with Terracotta.
- Workaround: Change the policy file, commenting out all of the defaults and adding just this:
```
grant {
     permission java.security.AllPermission;
   };
```

CDV-254 Class sharing under IBM VM issues with DSO.
- Workaround: Disable class sharing (-Xshareclasses:none).

This release supports the use of the THashMap and THashSet classes from the trove library (http://trove4j.sourceforge.net/, only version 1.1b5 is officially supported in this release). THashMap and THashSet support the use of user-customized hashing strategies through the TObjectHashingStrategy interface. When distributing THashMap/THashSet instances, only the default hashing strategy is supported. Any custom hash strategy will not be honored across the cluster.

Terracotta Sessions Configurator creates a test environment that depends on running two domains (instances) of a web container (AppServer) from a single install source. IBM WebSphere CE does not support multiple domains in a manner that is compatible with Configurator. However, you can use Configurator to test a web application deployed on Apache Tomcat. After configuring your web application to run clustered with Terracotta Sessions, use the generated tc-config.xml file to deploy the web application on IBM WebSphere CE running with Terracotta Sessions.

OOME in Permspace

SEVERE: Error deploying web application directory search
org.apache.commons.logging.LogConfigurationException:
java.lang.OutOfMemoryError: PermGen space (Caused by java.lang.OutOfMemoryError: PermGen space) at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:538) at ...

Increase the permspace by passing the correct jvm arguments.

Max server object count capped by int
There could be some unexpected behavior if the database has more than max int/2 objects in it.

Possible double notifies after server restart
It is possible to receive double notifies on server restart
- This is caused by
  - Thread1 is selected to be the notified thread in the server and the
    notification succeeds
  - The server crashes
  - When the server comes back up and the outstanding transactions are re-sent, the server chooses a different thread to be the notified thread and THAT notify also succeeds.
- The solution is
  - On the receiving client side, keep track of the server transaction id that caused the notify.
  - On client reconnect, the client lock state should contain the notifier
    server transaction id
  - The server lock manager can then decide whether or not to choose a notified
    thread for a given transaction based on whether that transaction's notified
    thread has already been applied

Changes to the default batch size made to improve memory performance, may in some cases affect a class of performance tests. Please contact support@terracottatech.com if this occurs.