Greg Luck's Blog

After 10 months of development, ehcache-1.2 has been released.

Thanks to all the developers who contributed to the release through feature requests, bug reports and patches during the beta program.

The 1.2 release of ehcache has many new features including:

• Flexible, extensible, high performance distributed caching. The default implementation supports cache discovery via multicast or manual configuration. Updates are delivered either asynchronously or synchronously via custom RMI connections. Additional discovery or delivery schemes can be plugged in by third parties.
• New FIFO and LFU caching policies in addition to the standard LRU.
• Introduced CacheManagerEventListener and CacheEventListener interfaces and default implementations.
• Multiple CacheManagers per virtual machine.
• Programmatic flushing of application state to persistent caches
• Significant (up to 7 fold) DiskStore performance increases.
• API for Objects in addition to Serializable. Non-serializable Objects can use all parts of ehcache except for DiskStore and replication. Two new methods on Element: getObjectValue and getKeyValue are the only API differences between the Serializable and Object APIs.
• Backward Compatibility with ehcache-1.1. All users of ehcache-1.1 should be able to upgrade to ehcache-1.2.
• Tested with Hibernate2.1.8 and Hibernate3.1.3, which can utilise all of the new features except for Object API and multiple session factories each using a different ehcache CacheManager. A new net.sf.ehcache.hibernate.EhCacheProvider makes those additional features available to Hibernate-3.1.3. A version of the new provider should make it into the Hibernate3.2 release.
• Tested with ehcache-constructs.
• Apache 2.0 license

Enjoy!

Well another weekend spent on ehcache.

Added a long requested feature to accept keys and values that do not implement Serializable. This makes ehcache suitable for a lot more purposes. I was always afraid of the subtleties involved with NonSerializable Elements getting into the system and then not being able to be persisted to DiskStores or replicated. But it is just a matter of gracefully degrading and logging warnings. It was quite simple really.

Also fixed some minor bugs to do with rare edge conditions. This makes ehcache more robust.

There is only one old bug to fix. No patches to process. And pretty much all the feature requests that are going to get into this release are in.

So what is stopping me from releasing 1.2? I am getting desperate for reasons not to release it. The problem with open source projects are either no one uses them and you can change them as often as you like, or they are widely used like ehcache and you become ultra cautious.

I probably want to do the following before I release:

- fix that last bug
- I promised the Hibernate guys a new ehcache plugin.
- more torture tests for replication.

Perhaps next weekend…

For a couple of weeks now I have been an ex-ThoughtWorker rather than a ThoughtWorker. It turns out there are a few of us, and Adwale Oshineye has thoughtfully created an alumni aggregator at blogs.thoughtworks.com/alumni. Being a consultant can require a big travel commitment, so for a lot of people consulting has a limited lifespan.

Now that I am no longer aggregated on the main page of blogs.thoughtworks, I feel I can make the occasional wry comment. Also, TW Australia is headquartered in Melbourne, Victoria, upon which I am about to play a prank.

I am been doing a lot of driving lately down to my 40 ha (100 acre) farm. I notice a lot of Victorians on the roads here in Queensland, a good 1700km from home. As I drive I cannot help notice the wording on the number plate. Some say “On the move” and some say “The place to be”. In fact the plate has changed from “On the move” to the “place to be”. Let me repeat that: on the move to the place to be! How unfortunate when you see those number plates outside of Victoria.

I am moving my Blog+Wiki to Movable Type. SnipSnap has served me well. It is Java based, which suits me fine, because I am a Java guy. I run several Linux boxes from my home, which are permanently Internet connected.
However I am planning to move overseas for a year with my family. We will be leasing our house, so I must find a new home for either my servers or my sites. I was quoted a cost of co-location of $200 per month per server, which for my two servers would be $4,800 for the year. I can move the sites to a shared Linux environment for $150 per year.
Doing so requires me to move my commercial software site http://simonsayssoftware.com.au and my non-commercial blog to LAMP technologies. So that’s what I am doing.
Hosting companies require those wishing to run Java to either use a dedicated server or co-locate. Why is that? In two words, the Virtual Machine. Java is plenty fast enough compared with PHP or Perl. The problem is the memory the VM consumes. On a shared environment, you need to use small amounts of resources, and then hand them back when you are done. The Java VM grows and rarely shrinks. I have never seen one shrink by more than a few percent. This is customisable but still very limited.
So, will Java always be a non-starter for the shared environments of hosting companies? There are two reasons for optimism.
Firstly, JDK5 introduces Class Data Sharing to Sun-based VMs. See http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html. Apple have been doing this for a while on OS X. See http://developer.apple.com/documentation/Java/Conceptual/Java141Development/index.html. Sun claims a saving per VM of at least 6MB.
Secondly, there is the Gnu gcj project, which provides Java compiled to native code. It does not use a Virtual Machine. See http://gcc.gnu.org/java/. This project is rapidly maturing. On Fedora Core 2, a whole stack of Java applications compiled with gcj are available, including ant and Tomcat. RedHat are the ones pushing hard for this. I remove these at the moment, because they are the wrong versions for my work and system-wide stuff gets confusing. Having had a read of some user experiences, it seems that it is still a bit raw. If it matures into a first-class Java implementation, then I think the way will be open to use Java on shared hosting environments.
The problem with Virtual Machines is that they generally do not hand back to the OS memory freed from the VM Heap after garbage collection. It depends on the application, but for an application using 100MB of RAM, free memory will be significant, and at times in the order of tens of megabytes. Gcj promises to solve this problem.

continue reading…

continue reading…