~pperalta

Anyone that follows me may have noticed no updates for the past few days. Somehow my account (http://twitter.com/patrickperalta) stopped working without any clue as to what could be the cause. Since I can’t log in to report a trouble ticket, I’ve sent an email to support at twitter.com, but I’m not holding my breath for a response anytime soon.

Strange thing is that I can still read updates from those that I’m following through Tweetie and TwitterFon, but no updates from me.

This Thursday will be the next Coherence SIG in New York. Check out this new Coherence Blog by PM Craig Blitz for more details. I will be talking about POF (the Coherence platform neutral high performance serialization library), including some new features coming out in Coherence 3.5.

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.