Greg Luck's Blog

Ehcache has configurable correctness and coherency settings. A good, though not complete analogy is database isolation settings.

So, within an Ehcache cache clustered with Terracotta, you have:

I went to DevNexus in Atlanta a few weeks back. Neal Ford gave a talk on predicting the future. Neal is a great speaker and I found it very thought provoking. Now as a former colleague of Neal’s I also felt challenged to think about whether I agreed with him. Neal is a super-smart polyglot coder who does not quite view the world the way most devs do.

Here is my list and justifications for each. Some of these disagree with Neal’s predictions.

Will developers have to deal with the challenges of parallelisation in CPUs? No.

Neal said yes, and that this was justification to go with something like Scala with its Actors to avoid learning threading in Java. I say no, and here’s why.

The issue is real enough. Core frequency has stopped increasing and CPUs are getting more cores. Lots more cores. For example, the Sun Fire X4640 server comes with 4 to 8 Six-Core AMD Opteron processors. That’s 48 processors. The normal threading approach has been to use monitors where one thread at a time gets exclusive access to an object or a synchronized block. That works well with small numbers of cores, but not with lots. What happens is that more and more time gets spent waiting to acquire a lock. The newer approach avoids this as much as possible with a whole slew of tricks such as immutable collections like CopyOnArraySet and CAS.

So will devs have to deal with this? No. Why? Because in the Java world developers are mostly protected from multi-threading. Instead the JDK (think java.util.concurrent), web containers and app servers (think Glassfish, Jetty and Tomcat) and libraries, like my own Ehcache have to deal with this. Those libraries that do get to play in this new world. Those that don’t will fall by the wayside. But it is these product and project vendors who are affected, not the vast developer population.

One ring to rule them all… Maven

William Gibson once said “The future is already here. It’s just not very evenly distributed.” A few years ago I banked on Maven becoming a big deal and decided to back it big time. I converted Ehcache to it and the corporate stuff I was doing too. Everywhere. People complain that Maven is too complicated. Well, the problem is complicated. I admit that Maven ranks up there with EJB in its difficulty. But it is getting better. Maven sets lofty ambitions for a system of world-wide component development, and is largely successful. Hats off to Jason and co.

I surveyed my audiences on my recent US tour. In Silicon Valley, 60% used Maven. In the rest of the country about 40-50%. Where is the future already here?

Swallow the red pill.

Brave new polyglot world

4 years ago, fearing I was missing out on the dynamic language revolution, I learnt Python and then Ruby, both of which were in use at my workplace. That was useful and fun.

Now, as Java developers it is difficult not to feel inadequate unless you know Java and a couple more JVM languages which in order of descending popularity I believe are: Groovy, Scala, JRuby, Cloujure, Jython ….

Ok, so how many people can code fluently in Java and one of these in the same day?  Well, I asked my audiences. Answer: < 5%. Which thinking back jelled with my corporate experience. There were two guys, both brothers, who were polyglots. And a few pretenders. And the rest of us struggled.

For the record I am saying that we all need to know at least XML, HTML, CSS, JS, shell, maven, ant – no argument there.

Neal suggested that projects would be written in multiple languages because “that’s how ThoughtWorks Studios does it and that is the future”. Not. ThoughtWorks is filled with polyglots like Neal – which is not representative of the community at large.

My prediction is that a whole project will be written in one JVM language, whether it be Java or one of the others.

Of course a given project can exploit existing libraries which are in byte code form independent of the language they were written in. Incidentally, to support this world, Ehcache is in Grails, has a very useful Groovy caching framework called SpringCache (it is for Groovy not Spring though), has a JRuby GEM and so on. In other words we make ourselves available

Self Healing Open Source

I sometimes worry about the future of Java with the consolidation that has happened – not just the Oracle acquisition but things like Spring. It is a different world than the one we were in 5 years ago. Something similar happened in Unix, which started off free in the 1970s but by the late 80s was dominated by commercial vendors who were in the Unix Wars.

What happened? Linux.

Before turning off the lights, Sun open sourced pretty much everything they owned. That creates a legal basis for the forking of that code into new projects if the open source community feels it needs to self-heal.

So will it? That depends on the vendors. But I think we as developers are safe.

Virtualisation and that cloudy stuff

Love it or hate it, virtualisation is here to stay. Get over it.

Are there problems? Yes. Do the cloud environments create even more problems? Yes. But this is a sea change in our industry which is mostly about freeing us from sysadmin costs and is therefore unstoppable. Get on board or become a dinosaur.

Global Warming

I read a book 5 years ago called The Skeptical Environmentalist which argued quite convincingly a whole host of politically incorrect views, most notably that there were multiple explanations for the warming observations such as the sun spot level. Bjørn Lomborg was pilloried for this and formally investigated for scientific dishonesty. He prevailed.

So at the time my view was that the case was unproven. The nice thing about empirical science is that theories can be falsified with more data. An of course the more data we get the more probably it becomes that global warming is real and is not a problem that will solve itself.

So for some non-Java predictions:

1. Global warming will eventually be proven to most people’s satisfaction (think evolution) to be correct
2. Despite the heroic efforts of the Europeans amongst others, some serious warming will occur
3. This will happen in a perfect storm with the rising cost of fertilizers (based on the price of oil) rolling back a chunk of the green revolution of the 60s
4. There will therefore be lots of hot, thirsty, hungry people looking for a new home
5. New Zealand is one of the few places in the world predicted to be little affected by global warming
6. lots of people will want to move to New Zealand

So the smart money would say “Apply for New Zealand citizenship now and beat the rush”.

Ehcache Server provides a RESTful API for cache operations. I am working on v0.9 and have been doing some performance benchmarks. I thought it would be interesting to compare it with the performance of that other over-the-network cache, Memcache. Now I already knew that Ehcache in-process was around 1,000 times faster than Memcache. But what would the over-the-network comparison be.

Here are the results:

Memcache and SpyMemcache Client
10000 sets: 3396ms
10000 gets: 3551ms
10000 getMulti: 2132ms
10000 deletes: 2065ms
Ehcache 0.9 with Ehcache 2.0.0
10000 puts: 2961ms
10000 gets: 3841ms
10000 deletes: 2685ms

So, the results are a wash. Memcache is slightly slower on put, maybe because the JVM does not have to malloc, it already has the memory in heap. And very slightly faster on get and delete.

A few years ago there was a raging thread on the Memcache mailing list about Memcache versus MySQL with in-memory tables. They were also a wash. I think the point is that serialization and network time is more significant than the server time, provided the server is not that much different. And this is what we see with Ehcache.

And now for the implications:

1. REST is just well-formed HTTP. Just about any programming language supports it. Without having to use a language specific client, like you need to do with Memcache. Ehcache Server was the first Java cache to support the REST API. But many others have followed. Why? It is a really good idea.
2. Performance wise, REST backed by a Java App Server and Cache, is about as fast as Memcache.
3. Therefore, your decision on what to use should depend on other things. And Memcache is no-frills. If you chuck Terracotta in behind Ehcache (we are one company now after all) then you get HA, persistence, and coherence expressed how you like, as a guarantee that you any reading the last write or more formally in XA transactions.

Finally, I will be giving a Webinar in a few weeks where I compare Ehcache and Memcache.

The last time I was in the US a few months ago I was told that the grace period for the new ESTA US Non Visa Waiver program would expire in a few months. Because that time was not up, I did not apply.

While this is true the US Department of Immigration in addition requires all Air New Zealand travellers to use the ESTA program. So on attempting to board we had to apply. No problem.

I searched for “us visa waiver australians” and up came three “Sponsored Links”

1. ESTA Application Website

   www.estaaustralia.org Welcome to the U.S. ESTA Application Website.

2. ESTA Application Website

   www.ESTA-au.org Welcome to the U.S. ESTA Application Website.

3. Australian Travel Advice

   www.smartraveller.gov.au Check out the information that is not in your guidebook before you go

I filled out the applications on the first link. AUD53 payment was required for each which I provided by credit card.

Then back to the check-in counter. The applications had not come through which was strange. Then they said there is no fee. Finally they have leaflets for the site you are meant to use which is https://esta.cbp.dhs.gov

This smelt like a scam. Air New Zealand rang the US Consulate who confirmed that I had not been registered, and then pointed out that I didn’t need to be because the grace period was not over

Final call was to the Commonwealth Bank to cancel my credit card and dispute the payments. A fun boarding.

I have released a new version of Ehcache, 1.5.0-beta1, which provides a host of new features and a few bug fixes. Some of the features are up to a year old, so this pretty large release is a chance to clear the decks ahead of some exciting new work coming in 1.6, such as the ehcache Cache Server.
Please dive into this version and let me know if you find any issues. I am hoping the tyres will be kicked by enough people to do a final release in 3-4 weeks’ time.
New Features
Added JGroups Implementation. Thanks to Pierre Monestie for the patch(es) for this. Though new to the core distribution JGroups replication has been in production use in a large cluster for the last year. This does not create a dependency on JGroups unless you want to use this replicator. That will be made clearer when it is moved to a separate module before final release.
CachingFilter performance improvements,
Constructs performance improvements
added loadAll() to the loader implementation to enable preload without specifying keys.
diskPersistent now can be used with caches that use only MemoryStore in normal use but want to persist to disk
DiskStores are now optional. The element is now non-mandatory. This will simplify configurations particularly where multiple CacheManagers are being used. If one or more caches requires a DiskStore, and none is configured, java.io.tmpdir will be used and a warning message will be logged to encourage explicity configuration of the diskStore path.
The default RMI based cache replication can now configure a RemoteObject port so that it can be easily configured to work through firewalls. This is done by adding a new property remoteListenerPort to RMICacheManagerPeerListenerFactory to enable it to be specified.
Added a new system property expansion token “ehcache.disk.store.dir” to DiskStore configuration which can be used to specify the DiskStore directory on the command line or in an environment variable.
e.g. java -Dehcache.disk.store.dir=/u01/myapp/diskdir …
Added the ability to specify system property tokens using $tokenname in ehcache.xml which are then replaced when the configuration is loaded.
Updated the remote debugger with enhanced reporting and better documentation (See Logging page in the documentation).
The new version prints a list of caches with replication configured, prints notifications as they happen, and periodically prints the cache name, size and total events received.
Summary of Bug Fixes
CachingFilter bug fixes for various rare edge conditions
Major speed up to shutdown process when diskPersistent is not being used
Fixed various shutdown exception when both Hibernate and Spring both try to destroy caches

I sat down at my newish PowerMac this morning to do some hacking. I bought it in January 2006. It has a 149GB hard drive which is now full. My wife complained about iMovie HD being a little slow, which should have been a warning sign. Anyway time to dust off my old script to find the large files on the computer. I initially forgot I had such a script. I googled for something to grab and did not find much. So I will put this on my blog in the hope the next time I am looking for it it will be easier to find.

I am thinking about writing a Dashboard widget to do this. I wrote my first widget last night. It embeds a DOJO widget. Very nice and easy, with a few gotchas not covered in the documentation. I will blog about that another time. Why write a widget to execute a simple script? I am realising that there is a growing group of Mac power users who have not discovered the joy of Unix, and are probably unlikely to.

find . -type f -size +500000c -exec ls -ldh {} ; 2>/dev/null

The script above find all files from the directory you are in down of size greater than 500,000 bytes. Change the number up and down as desired. You will need to be root to find all files on the system. On Mac OS X it is a good idea to start at /Users, which is where most of the stuff you might want to delete will be.

And what you might be wondering did I find. We bought a Sony HDR-HC3 High Definition wide screen camcorder a few months back and have been shooting hi-def movies ever since, along with 4MB photos.

I am writing this on Writely which has impressed me with its WysiWig editing in JavaScript.

I have been doing a lot of architecture work lately using Confluence and discovered they have a Rich Text Editor mode.
It turns out that it, like Writely, does not support Safari as yet. I am using it in Firefox. But Confluence is using tinymce
(http://tinymce.moxiecode.com/) and it is cool.

One of the best things is that you can search within the page you are editing. Browsers do not support finding withing form fields,
which is what you are doing in the wiki editing mode. The ability to do this is huge. Writely also supports this. It is because I guess
it searches the DOM, and these tools write to the DOM as you type.

We have a Python based monitoring application that regularly tops the CPU list, using more CPU than the application it is monitoring.

I am a bit of a newcomer to Python. It is in stable 8th position on the Tiobe programming index (http://www.tiobe.com/tpci.htm). It is mature, has tons of libraries available for it and is suitable for a broad range of tasks.

Python is Sloooooooow

There is something wrong with the monitoring app being hungrier than the app it is monitoring.

So, how fast is Python? Benchmarks always seem to lead to lots of fights. My raw data, and my subesquent conclusion, are based on:

1. A loop test I wrote. Java was 200 times faster. I had some Python guys look it over. It is valid but is most likely bad because int are primitives in Java but fully fleged objects in Python.
2. Computer Language Shootout: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=java&lang2=python

   The graphical results for a series of different benchmarks are shown below. Java is up to 150 times faster. The average is around 10 times faster.

   

3. http://www.timestretch.com/FractalBenchmark.html This benchmark is 1.25 seconds Java, 15 seconds Python. Java is about 10 times faster.

My conclusion is that Python is about 10 times slower than Java. (Though not of interest right now, I also took a look at Ruby. It seems to be about 15 times slower). Does this matter? Right now we have a problem and it does matter.

Fixing It

So, what to do? The Python books I have suggest using C libraries for the bits that are slow. So, how to tell what is slow? Fortunately Python comes with a very simple and easy to use profiler. To add profiling to your app simply:

import profile
profile.run(‘main()’) #or whatever your entry point is called

We did this for our monitoring app and found, sure enough, that the largest performance antipattern of all time had reared its head yet again: XML. In our case it was a python lib called tramp xml. It works recursively and seems to hit all the bad points of Python performance. Fortunately we can change our file format to non XML and avoid the issue.

What about psyco?

We also considered accelerating Python with pysco. (http://psyco.sourceforge.net/).

We are running 64 Linux on AMD64. So the requirement for “A 32-bit Pentium or any other Intel 386 compatible processor. Sorry, no other processor is supported. Psyco does not support the 64-bit x86 architecture, unless you have a Python compiled in 32-bit compatibility mode.” sort of kills it for us.

Secondly, pysco is being deprecated in favour of PyPy (http://codespeak.net/pypy/dist/pypy/doc/news.html) PyPy is not yet ready for primetime.

What about a C Lib?

The usual solution to Python performance problems is to use a C library to speed up whatever is your chokepoint in Python. I think that is a valid approach, and one we would have used had we not been able to simply remove the XML.

What about Jython?

I have been playing with Jython lately. Unfortunately Jython does not use the JIT, so Java performance sucks.

Conclusions

1. Python is slooooow. 10 times slower than Java, which itself is about two times slower than C.
2. If you are not a C shop, the usual solution of porting the slow bits to C will be a bit too hard
3. As more production apps migrate to 64 bit AMD64 and EMT64, pysco falls away as a solution. (For non 386 it has never been an option)
4. Carefully consider the performance requirements of your application before you select Python as the implementaiton language.

Can Google be used to measure the popularity of something? Maybe. That is the approach of the famous TIOBE Programming Community Index. ( See http://www.tiobe.com/tpci.htm).

As the maintainer of an open source project, it is something I look at. I am happy to that ehcache now returns more results than any other Java cache with 348,000 results.

So, is is the most popular? Who knows. But downloads and google suggest it is.

(I have been very quite lately. This is my first post in 7 weeks. Blame it all on a new job. I do have some pent up blogs though…)

I have just become a new member of JSR-107, the caching API. This one has been around for a long time and has gotten bogged down. I am shortly going to start an ehcache implementation of JSR-107. I have already done a first pass over ehcache and added extra features and done some restructuring to make that job a lot easier.

The key benefit I can see in JSR-107 is that, if it becomes the standard, like JDBC, then you can write to it and have an almost zero cost of switching to a different caching provider. At present, users of Hibernate and Spring have much the same benefit, based on the cache plugin approach taken by those tools. But there are many caching users who use cache APIs directly. They will get the same benefit.

Hopefully this will also encourage cache implementations to provide a lowest common denominator of functionality.