~pperalta

Recently I was helping a customer install Coherence*Web on a JSF application. After running the install and deploying the war file, I saw the following exception:

javax.servlet.ServletException: Error while saving state in 'session': 'session attribute for name "/Page1.jsp" does not implement Serializable; class: Class javax.faces.component.UIViewRoot

HTTP session attributes must be serializable in order to place them into a distributed cache. This requirement is not unique to Coherence*Web, any session replication solution will require this in order to replicate sessions to another JVM.

However, Coherence*Web does have a feature that can let you work around this. If you place a non serializable attribute into an HTTP session with sticky session optimization enabled (see description of this feature at the bottom of this link), the attribute will be placed in a local cache (and a warning will be logged.) The idea is that if a sticky load balancer is managing the traffic, the chances are very good that subsequent requests for that session will go to the same JVM which is holding that attribute in memory. Obviously if the load balancer sends the request to another JVM (or if the JVM leaves the cluster) that session attribute will not be available in the request. Therefore this is not a recommended approach; this feature is meant to ease the transition of a web application from a single JVM to a distributed environment.

So it appears that JSF is placing some sort of view metadata into the session that isn’t serializable. The good news is that JSF can be configured to store this data on the client side (as a hidden form field) instead of the server side (in a session.) This change needs to be made in web.xml; change this:

  <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>server</param-value>
  </context-param>

to this:

  <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
  </context-param>

More information on this setting can be found here:

http://java.sun.com/developer/technicalArticles/GUI/JavaServerFaces/

I do find it odd however that they have the ability to write out the state to the client, but the object that holds this state isn’t serializable for some reason. I wonder if this was an oversight or if this is by design.

Earlier today I was pinged by Mike Levin; he wanted to pass along the message to all of my fiercely loyal followers (yes, both of you) that he’s out in Crested Butte enjoying the mountains, skiing, and the up coming Java Posse Roundup…and that you’re probably not. Of course it isn’t intended to make you jealous, but it looks like this is a pretty cool conference (small size, interesting topics, etc.) I hope that I can go one of these days! I went to their JavaOne BOF last year and had a great time (unfortunately I had to leave early to catch my flight home.) For those of you that don’t know the Java Posse, it is a podcast that covers everything that you need to know in the Java world. And it has a cool jingle. So that I can make this post relevant to Coherence, episode 7 is an interview with our dear leader.

Lately I have been helping customers set up the Coherence JMX Reporter. This is a new feature in 3.4 that will output statistics for the cluster to a CSV file that can be loaded into Excel for analysis. This feature can be enabled or disabled (it is disabled by default) in a running 3.4 cluster that has JMX for the cluster already enabled.

First, log into JConsole and take a look at the attributes for the Reporter MBean. The ConfigFile property points to an XML file that contains a list of reports to be executed (each report is also defined by an XML file.) The default value is reports/report-group.xml, however if you want to sample all of the OOTB reports, change this value to reports/report-all.xml. Alternatively, you can define your own reports based on the JMX information that you’d like to keep track of. These reports ship inside of coherence.jar.

After selecting the reports to run and (optionally) the IntervalSeconds (60 by default) and the OutputPath (defaults to the directory the JVM process is running in), flip over to the Reporter operations and select “start.”

Note: if using JConsole that ships with 1.6, you may have to specify that the IntervalSeconds is a long type. For instance, to specify a 30 second interval, enter “30L” without the quotes into the field. This is due to a bug in JConsole.

After starting up the reporter, you should see a few .txt files generated in the OutputPath. These reports are described in detail in the user guide. I opened up two of them (Cache Size and Memory Status and took a few screenshots of these files in Excel:

This graph is demonstrating the total size of the data in a cache.

The light blue line is showing the amount of heap allocated, and the red is showing the amount of heap being used.

One of the major challenges in distributed computing is the maintenance of the application. You need the ability to make changes to the system without breaking the current users of the application. Anyone who uses Java serialization knows that this is a difficult task, especially since the use of java.io.Serializable results in a brittle binary format.

In a previous life when I was the designer and developer of a services-style distributed system, I took a brute force approach. I determined that each version of a service would include a set of serializable objects and service interfaces. If any of the serializable objects needed to change, that would trigger a new version of the services. This meant having to keep several versions running at a time, one to support new clients, and the older ones to support older clients.

I was able to get away with this because the objects in the system didn’t live for very long. The life cycle of an object tended to start either in the DAO layer (Hibernate) and end up being serialized to a client, or a client would send a serialized object to a service which would end up being written to a database using Hibernate. Upon completion of the transaction, there were no longer any references to these objects (L2 caching was not enabled.) As a result, running multiple copies of the application in a single container was feasible as the memory requirements didn’t exceed the capacity of the heap.

An object in a typical Coherence system has a much longer life cycle; many times the objects themselves will need to outlive the specific version of the application that is running. Coherence allows you to do this by performing a rolling restart. This means that instead of taking down the entire cluster to perform an upgrade, you can take down a node, update its classes (and maybe configuration, depending on what is being modified) and restart it. This process is repeated until all nodes have been updated.

However if the objects in the cache have a different serialization format than the updated version of their classes, you can run into problems when attempting to deserialize a new data format with an old class. Consider the following scenario:

Node 1 is shut down and updated with a new version of class A. This new version of class A holds a reference to class B, which is a new class. Upon restart, node 1 begins to insert new instances of class A that contain class B. In the meantime, node 2 has not been upgraded yet and it makes a request for an instance of class A that has been inserted by node 1. Since it doesn’t know anything about class B, it throws an exception while deserializing.

The good news is that Coherence makes this problem easy to solve. Using Portable Object Format (POF), you can make your cached objects forward and backward compatible in order to deal with the scenario above.

Before Coherence 3.4, POF was used exclusively for Coherence*Extend, in particular for .NET clients. Starting with Coherence 3.4, POF is natively supported inside of the cluster and is the preferred serialization format for Coherence.

In order to accomplish this, you must implement the EvolvablePortableObject interface.

• This means that you must write out the serialization routines (readExternal and writeExternal). Although somewhat tedious, this will pay off as POF serialized objects are smaller than their Serializable counterparts, and take less memory and CPU to serialize.
• EvolvablePortableObject extends the Evolvable interface, so these methods must also be implemented. The easiest way to do this is to extend AbstractEvolvable. The JavaDoc for Evolvable goes into detail about how it works, but the basics are that by implementing this interface, Coherence will automatically resolve differences between class and data versions.

Here is an example implementation:

import com.tangosol.io.AbstractEvolvable;
 
import com.tangosol.io.pof.EvolvablePortableObject;
import com.tangosol.io.pof.PofReader;
import com.tangosol.io.pof.PofWriter;
 
import java.io.IOException;
 
 
public class Person
        extends AbstractEvolvable
        implements EvolvablePortableObject
    {
    // ----- constructors ---------------------------------------------------
 
    public Person()
        {
        }
 
 
    // ----- accessors ------------------------------------------------------
 
 
    public long getId()
        {
        return m_id;
        }
 
    ...
 
 
    // ----- Evolvable interface ---------------------------------------
 
    public int getImplVersion()
        {
        return VERSION;
        }
 
 
    // ----- PortableObject interface ---------------------------------------
 
    public void readExternal(PofReader in)
            throws IOException
        {
        m_id         = in.readLong(0);
        m_sFirstName = in.readString(1);
        m_sLastName  = in.readString(2);
        m_sEmail     = in.readString(3);
        }
 
    public void writeExternal(PofWriter out)
            throws IOException
        {
        out.writeLong(0, m_id);
        out.writeString(1, m_sFirstName);
        out.writeString(2, m_sLastName);
        out.writeString(3, m_sEmail);
        }
 
 
    // ----- fields ---------------------------------------------------------
 
    private long   m_id;
    private String m_sFirstName;
    private String m_sLastName;
    private String m_sEmail;
 
    public static final int VERSION = 1;
    }

A POF configuration for such an object may look like this:

<!DOCTYPE pof-config SYSTEM "pof-config.dtd">
 
<pof-config>
  <user-type-list>
    <include>coherence-pof-config.xml</include>
 
    <user-type>
      <type-id>10000</type-id>
      <class-name>com.tangosol.examples.evolvable.Person</class-name>
    </user-type>
 
  </user-type-list>
</pof-config>

To configure Coherence to use POF, the easiest method is to configure the following system properties in your startup script:

-Dtangosol.pof.enabled=true 
-Dtangosol.pof.config=pof-config.xml

Now let’s say you have a running system and you want to add a new Address field to the Person class. The following modifications can be made to Person:

    // ----- PortableObject interface ---------------------------------------
 
    public void readExternal(PofReader in)
            throws IOException
        {
        m_id         = in.readLong(0);
        m_sFirstName = in.readString(1);
        m_sLastName  = in.readString(2);
        m_sEmail     = in.readString(3);
        m_address    = (Address) in.readObject(4); // <- new Address field
        }
 
    public void writeExternal(PofWriter out)
            throws IOException
        {
        out.writeLong(0, m_id);
        out.writeString(1, m_sFirstName);
        out.writeString(2, m_sLastName);
        out.writeString(3, m_sEmail);
        out.writeObject(4, m_address);  // <- new Address field
        }
 
 
    // ----- fields ---------------------------------------------------------
 
    private long   m_id;
    private String m_sFirstName;
    private String m_sLastName;
    private String m_sEmail;
    private Address m_address;  // <- new Address field
 
    public static final int VERSION = 2; // <- new version
    }

And this addition to the pof-config.xml file:

    <user-type>
      <type-id>10001</type-id>
      <class-name>com.tangosol.examples.evolvable.Address</class-name>
    </user-type>

There are the changes that I made:

1. Added the Address field as a member of the Person class and to the serialization routines (as index 4)
2. Incremented the version
3. Added the Address class to the POF configuration

That’s it! Now clients with an old version of the Person class can load new versions of Person data, modify it, and place it back into the cache while preserving all of the new data (for a hint on how this is done, take a look at the futureData property defined by Evolvable. The obvious caveat here is that new fields must always be added to a class, and the order must be preserved.

There are some Coherence related activities this week that the user community may be interested in.

First, the Winter 2009 NY Coherence SIG will be on Thursday January 29th at the Oracle office on Madison Ave in midtown. Registration is required in order for the bouncers in the lobby to let you in, so be sure to check the link and register if you plan on attending. Yours truly will be talking about using Coherence in production and a peek behind the scenes at the tools and techniques used to provide support for Coherence. We’ll also have one of our customers (Anthony Casalena, Founder and CEO of Squarespace, Inc.) presenting as well as one of our top architects Brian Oliver speaking about using Coherence in a WAN. He just gave a presentation at the London SIG last week that was well received.

For those in the Boston area, you can check out the Boston Scalability User Group in Waltham run by Anthony Chaves. Here is the registration link if you’re interested in attending. This meeting will be a free format discussion on all things scalable, so if you have any questions about a new project or experiences (good or bad, the latter being more entertaining) you’d like to discuss among your peers this is a good opportunity to do so. I should be at this meeting as well.

Update: Due to the weather the Boston SUG meeting has been postponed.

In the virtual world we have a new LinkedIn Coherence Users group that has attracted over 30 members on its first day! If you’re a Coherence user or are interested in networking with Coherence users and architects, feel free to join this group.

While I’m in NY for the SIG, I’m going to try to take some time to check out Joel’s new downtown office.