Coding the Architecture - QCon: Open Terracotta

Re: QCon: Open Terracotta

Kevin Seal — Wed, 16 May 2007 10:18:36 GMT

I was hoping to take a fairly serious standalone Swing desktop application (no server involved) and use Terracotta to replicate a simple user interaction between two instances.

For example, I'd start up two instances of the application and update something in the model via one instance and watch it get updated in the other instance.

The application I had in mind is substantial although I was only interested in distributing one model from it (albeit a very large and pervasive one).

This was an artifical requirement and had no practical use for the application in question. The hope was to find out how easy it was to use Terracotta with something that wasn't designed with this behaviour in mind and whether a noticeable performance overhead was incurred. As it turns out I never got it to work - the model was far too complex to be a successful candidate for clustering; Terracotta demanded that I distribute more and more components until I finally came to the conclusion that while clustering may be relatively trivial to implement with Terracotta it's still not something you can retrofit into an unaccommodating design. Kinda obvious in hindsight.

I hope to give it another go someday when I get the time, but perhaps on something a little more amenable!

If you want to get a feel for the overhead and performance, though, you could do a lot worse than trying out the examples that come with Terracotta - they're basic but pretty good.

Re: QCon: Open Terracotta

Anjan Bacchu — Tue, 15 May 2007 17:39:38 GMT

Hi there, "At the moment I can't wait to take it for a test drive on something stupid like a clustered Swing application " interesting to know about your plans for a clustered swing app. I am interested to know about the memory and performance characterestics of this app. Are you clustering the Swing app or the server that serves the swing app ? Thank you, BR, ~A

Not so cool...

Kevin Seal — Tue, 03 Apr 2007 10:31:47 GMT

Well, after having spent several fruitless train journeys trying to get Terracotta to cluster an existing application I've finally given up, coming to the conclusion that Tim was probably right; clustering really isn't something that you want to implement transparently.

I could probably have managed to achieve clustering of my app's state but it would have involved rewriting portions of my code - it just wasn't designed for this sort of thing. I've endured running out of heap space (why?!) and the JVM terminating whenever it doesn't like something (excusable?), messages instructing me that my loggers are being distributed (ah.) and even a cold-call offering professional services support (in response to a blog entry?!).

Admittedly, Terracotta makes no claims that clustering should be bolted on post-hoc or taken on lightly; it simply provides a familiar programming paradigm for achieving it. While it's transparent to your Java code, it's not transparent to your Java development.

I guess what I've learned is that if you want distribution, you still need to think long and hard about it. The cost of implementation may be reduced by using something like Terracotta, but that doesn't mean you can leave the implementation to "cheaper" developers - the complexity of the problem remains.