POJO Mojo

Wow,

it has been a crazy week. I will try to pull together a list of links to folks who covered our open source announcement. Things have been absolutely insane though. So much so, that I won't be able to attend the Spring Experience this week. I was looking forward to meeting up with Rod, Rob, and Adrian in person. I was also hoping to attend some of the sessions on 2.0 updates, etc. Anyways, Terracotta will be there. If you are interested in speaking with us while at the conference you should seek out Jonas Bonér (he is presenting there) or Gary Nakamura. They will likely be in Terracotta t-shirts or button downs. I would LOVE it if anyone thinking about use cases for clustering Spring Beans would seek out Jonas and Gary and get your ideas over to us. With our going open source, you can also talk to them about becoming a committer, contributor, or getting more involved.

We welcome the community's input.

Read on for a non-exhaustive list of links about our announcement.

In general, I have respect for all engineers as the discipline is largely creative / artistic and there are myriad ways to solve one problem. And, I mean no disrespect to Venkat (the author); he was, after all, solving the problem with the tools he had readily available (and free).

But you should read this article referenced from TheServerSide today.

The suggested approach looks like at least 1 week's worth of coding, testing, and stabilization. Let's not even get into performance tuning. To share objects across JVMs, Oracle advocates JMS. This is absolutely an anti-pattern.

With open sourced Terracotta, this takes no extra code than the POJO you wanted to share in the first place. Do people actually build applications the way that article suggests? If yes, now is a good time to consider no longer doing so.

Terracotta Forge is planning to open its doors the first week of January, 2007. We have 4 projects in the works already, including:

• Glassbox
• Clustered Wicket
• Clustered Lucene RAM directories
• our own clustered CommonJ implementation

I am excited about the concept of having a single place for developers to go when looking to run their favorite frameworks in a clustered manner. Furthermore, people who have ideas for value-added services built on DSO will have a place to host and grow those projects, including direct access to the DSO engineers at Terracotta. Most importantly, Forge users will make solutions available to the community in a location people are coming to for clustering; you won't have to worry about how to generate traffic and awareness.

Please visit the site for info on the services the Terracotta Forge will provide for projects hosted there. Right now, we are just looking for project ideas. Please submit your projects using the instructions therein. Also, feel free to email me at [ari AT terracottatech DOT com] with your ideas (we are not heavy on process at the moment. Just looking for good ideas).

Also, feel free to download Open Terracotta and get started clustering your project while you are waiting for the hosting services to be constructed.

The benchmark results showed that XXX enables linear scaling of parallel processing across the grid as the grid (and the data set) increases in size and is limited only by aggregate CPU cycles across the grid. In the test, XXX was able to linearly scale from 2 million aggregations with two servers to more than 60 million aggregations across the 96 servers. This 30 times increase in processing throughput was achieved with only one tenth of a second increase in processing time, or 1.2 seconds compared to 1.1 seconds. Additionally, the tests demonstrated that the data grid storage capacity increases linearly as additional resources are added to the grid and is limited only by the amount of RAM available to the data grid.

Impressive numbers indeed. This vendor did a great job building scalable software. Lately, however, I have grown tired of claims of "infinite linear scale" and even "linear scale." Look at this paper. It calls 30 times (2 vs. 60MM aggregations) throughput from 48 times (2 vs. 96 servers) the servers "linear scale." It is in fact a 38% degradation in performance as the application scales.

Over the next few months, Open Terracotta will have significant performance and availability improvements added to it. In all the tests our customers and prospects have run, we have run faster than they expected (usually 10X faster than a serialization-based clustering solution), but it is very much use case-specific.

How do we as a community define a performance benchmark for clustering? Read on for my thoughts...