« Why should I look at Terracotta? Because bean-style gets tiresome | Main | Attributed And Redistributed: more Terracotta, in more places »

July 19, 2007

FUD OF THE WEEK

posted by ari

DEFINITION

According to Wikipedia, FUD is:

Fear, uncertainty, and doubt (FUD) is a sales or marketing strategy of disseminating negative (and vague) information on a competitor's product. The term originated to describe disinformation tactics in the computer hardware industry and has since been used more broadly. FUD is a manifestation of the appeal to fear.

Each week, I will attempt to seek out common misconceptions about Terracotta and explain why they are, in fact, misconceptions. I suspect that over time a pattern will emerge for all of us.

THIS WEEK

http://www.mail-archive.com/plug@lists.linux.org.ph/msg13454.html

In short, this mailing list entry hits 2 at once. "Terracotta is a single point of failure" or "Terracotta is a single point of bottleneck".

Terracotta clusters today in active / passive mode. This does not have ANYTHING to do with my application cluster (not sure if the original post is suggesting otherwise by use of the term "two-way cluster"). If I have 1 or 1000 nodes running Java, they can communicate using a Terracotta Server Cluster which acts as NETWORK ATTACHED MEMORY for my app cluster.

The passive Terracotta server is, in fact, an exact data replica of the then-active (replicating either via TCP or via shared disk). Failover for my application from speaking through the Terracotta Active Server to a new Active server is less than half a second. This is because Terracotta's Network attached memory concept works like network attached storage (file servers, but for RAM). When I mount a filesystem, I don't have to page it all into local memory in order to read part of a file, right? The same is true with Terracotta. Just connecting to a Terracotta server does not require my JVM to fault anything in. I can instead fault lazily. So, active / passive is indeed a viable strategy and Terracotta places no limits on my cluster's configuration...just on my Terracotta server cluster config.

Terracotta as a single point of bottleneck. Logically, network attached services can become a bottleneck. Sure. But, network attached services tend to have runtime caching and other optimizations that make them easier to scale than peer to peer solutions. My favorite is "greedy locks." Terracotta transparently replicates my lock state to the rest of my cluster so that, when I say synchronized(clustered object) {} , that carries through on the network. Java synchronization is pessimistic, but I cannot assume Terracotta must therefore go out on the network to acquire this mutex. In fact, Terracotta doesn't. It keeps central score of who is using which locks and allows any one of my application JVMs to check out a lock and keep it local-only until recalled back to the cluster. That means tight locking in a for-loop can be networked and still scale.

Most people would be amazed at the scale Terracotta has achieved under some of the world's largest websites. Also note that in many cases, it is possible to chop up your domain model so that it runs on more than 1 Terracotta Server. We have a use case in the lab right now with 100 million clustered objects (totaling 100GB) and the application is randomly mutating objects as fast as it can. The net result, 1200 object mutations per second per JVM and totally linear scale. That doesn't sound like a bottleneck to me.

Keep 'em coming guys! This should get interesting!

Trackback Pings

TrackBack URL for this entry:
http://blog.terracottatech.com/cgi-bin/mt/mt-tb.cgi/13

Comments

Posted by: Jorge De Flon at July 28, 2007 2:33 PM

Post a comment

Name:

Email Address:

URL:
Remember Me? YesNo

Comments: (you may use HTML tags for style)