> Our present product has a proprietary servlet code base.
> The engineer who put this in place has recently left our
> company and while I understand some of it, there is little
> javadoc or info other than bugging him.
Interesting. You may be able to cluster it with Terracotta directly without significant changes. Terracotta DSO clusters POJOs so if your servlet relies on a cache you can just flag that cache as clustered and see what happens. Might even be zero code changes.
> We have a product that should it work, it could scale to
> millions of end users and third parties alike, although
> naturally that takes time to achieve, so we've got some
> time for the right solution.
> Like others, I am kind of taken aback about the idea of
> moving back into a stateful setup. Right now we don't use
> sessions at all, but we basically use a cache and database
> with a user id and/or email. Because we're small,
> everything resides in the cache once accessed.
Well, strictly speaking you are correct but if you have a cache, you have a precursor to state. You happen to be able to reconsistute your state across JVMs and restarts. With Terracotta, there is no difference. You flag objects as clustered at runtime and those objects persist across JVM restarts and stay in synch across JVM boundaries. This implies that you get the value of stateless operation (no single JVM is a point of failure) but with a stateful development model (which I believe is simpler...less code for sure).
> I am curious if moving to Spring, Hibernate, and
> Terracotta, if the ability to scale is fairly simple yet
> robust enough to eventually scale to possibly dozens of
> With all that said, is there any way to do something
> similar out of the box with Terracotta, or do you have to
> keep on adding servers to an ever growing cluster? Maybe
> there is no need, or advantage to the island approach?
TC scales by adding servers and not by creating "islands" or "buddies." Several customers have validated our product at dozens (up to about 150) servers. If we cannot scale in a particular use case, one could always go to a multiple-Terracotta-server approach which works much like your "island" example. Many JVMs work together coordinated by a Terracotta server, but you may end up with more than 1 Terracotta server either because too many objects exist or too much data.
> Also, I haven't yet checked, but is Terracotta lgpl or
> bsd, or is it gpl and thus I couldn't ship it with our app
> for deployment if we wanted to provide our app to others?
We are essentially MPL. I am not a fan of virality. BSD is good but Mozilla is quite permissive as well. With our MPL-style license you can rely on TC to build apps and not pay us a dime. You can also bundle us in software that you burn on CD and sell (or offer up for download) and still not pay a dime. But, if you choose to bundle and not pay us, you have to make it clear to your community that you rely on Terracotta technologies (much like MPL).
> IS there any examples to look at, maybe even use to get up
> and running, then rework for my app?
I would start here: http://www.terracotta.org/confluence/display/orgsite/Tutorials
> Curious how Spring, Hibernate and Terracotta work
> together. I have yet to play with Spring or Hibernate, so
> not sure if using Hibernate negates the ability to cluster
> with Terracotta, or if it's not as good as using strict
> SQL or what have you?
We are just on the cusp of getting Hibernate to work. Clustering Spring Beans works fine. Sign up to our mailing lists and check out the archives. There has been lots of discussion in the last 2 weeks on the topic of hibernate integration: http://www.terracotta.org/confluence/display/orgsite/Mailing+Lists
> Given that there is Spring Web Flow and the Spring MVC,
> which is the ideal solution with Terracotta? Not sure
> which is the better way to go yet, but I am familiar with
> MVC and the Web Flow looks a little more than we would
Terracotta works fine with both. Our session clustering product would get you going with clustered Spring Web Flow or MVC. But that product is bundled inside our flagship DSO product. Just download that, IMO. http://www.terracotta.org/confluence/display/orgsite/Download
> I was thinking we'd look to deploy on quad core dual cpu
> systems, possibly with about 8 to 16GB of memory each.
> Curious what sort of caching Spring provides that works
> with Terracotta with clustering as well?
Spring doesn't "cache" per se. It relies on the developer to code to design patterns that cache. (This is not entirely true nor is it a dig at Spring but the notion of caching is highly use case dependent.) In general, the marriage of Spring and Terracotta allows you to create Spring Beans that you assume survive restarts and, further, those Beans remain consistent when your app is deployed in a cluster. With Terracotta4Spring, you flag those beans you just coded up as "clustered" and Terracotta takes care of the rest. 1 config entry per bean. It is lightweight for the developer.
> Lastly, sort of off topic, but any of you have experience
> with 64-bit linux (Fedora, RedHat?) and the 64-bit JVM...
> to take advantage of the >4GB of memory? Are they rock
> solid, stable... we'll be deploying on JDK 1.5.
We have several clients running 20 - 30 GB JVMs. Only consistent problem I hear is not stability but GC pauses of "minutes."