Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

bchever wrote:

adun,

Thanks for writing.

I would suggest that you download the full product for your platform

https://www.terracottatech.com/downloads.jsp

and then look at the two demos, Shared Editor and Jtable. Both of these are swing applications that use Terracotta DSO.

We will get back to you on your other questions shortly.

Regards,

I'm aware that nothing prevents swing code from using model objects that are clustered via terracotta. that is not the issue, however. the real issue would be how terracotta behaves if such swing code (think of the shared editor itself) is running in 250 different JVMs of users all over the US, some of which are behind firewalls, others are behind slow VPNs, etc.

¿would terracotta DSO still deliver under those circumstances?
If it did, its value would be beyond scaling, but on the true enabling of distributed computing for easy-to-write eventful rich clients.

Hi.

I find terracotta very interesting. In our company, we value simplicity of development, and terracotta seems extremely in-line with our philosophy, however:

We do not make HTML applications. Our software is rich-client, and deployed via webstart.

The way in which "user generated" load is balanced by terracota in web applications seems easy to grasp, since web servers are in a lan with application servers and both webb and app servers are all terracotta nodes. To gain scalability one only needs a load balancer that redirects HTTP requests to any of the web servers, not even session affinity is required thanx to session replication.

However, how would terracotta help scale an application that is not web (HTML) based?
Our webstarted swing user interfases make RMI calls to the servers (server == RMI exported object, for analogy, think of "mostly stateless ejbs"). We have few exported RMI Objects, and when the CPU load of the server gets high, we can split the RMI objects in different hardware.
For us, the scalability limit resides in when one single RMI exported object is being called upon by too many users (thus, too many threads). I dont quite see how would terracotta help us reach higher scalability, or how to get a "cleaner java api" (avoiding RMI and the conciousness of remoting and having to deal with "how coarse grained must remote calls be", etc).

I fin'd myself very attracted to terracotta, but with our companie's rich client policy I find myself at trouble at argumenting any benefit we could get from terracotta for its price (vs coding clusterability of stateless services ourselves).

The only advantageous scenario I really see is if webstarted swing clients were terracotta nodes too, and thus all RMI would go trough the window, and eventful behavior coul dbe reached, however I fear terracotta is not designed for that (I mean, I suspect it's based on the assumption that all nodes in the cluster are nearby in a lan, not scattered trough WANS, behind firewalls, etc) ¿am I correct?.

We love simplicity, and because of that we chose not to jump into the j2ee bandwagon and instead chose to homebrew our own "rmi container", our own simplified api for remoting, and to use webstart for deploying rich eventful clients. ¿how can we make use of terracotta?

Anyway, if you could please send me a quote of terracotta's DSO licensing, I'd appreciate it.