Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

As Gary pointed out, you just have to download the right product to be able to cluster whatever you desire. See the deployment guide at http://www.terracotta.org/confluence/display/docs/Deployment+Guide.

Also wished to point out that the Terracotta For Spring product lets you do both - i.e. cluster Spring Beans and cluster HttpSession (just add a config entry <session-support> true </session-support>).

Hello Sriram:

I dropped you an email and we'd be happy to discuss the use-case in greater depth on July5. There seems to be a few questions in here and here is a summarization response, based on an internal discussion.

a.
Certain classes are immutable so they wouldn't be present in the change callback. Examples include:
- all the primitive wrapper classes (Integer, etc)
- java.lang.String
- java.lang.Class
- java.lang.StackTraceElement
- any non-portable object.
Other mutable objects that can change will be passed over to the change listener.

b.
In your example, additionally, you could be continuously passing over the changes to the MFC/C++ client - and the client applies changes, if the extent of the changes are small and hence network bandwidth consumption is reasonable/minimal. If that assumption is incorrect, then there would be, it seems, merit in an intermediary layer to compare deltas between object changes over a certain interval and pushes the net-change at the end of some predefined time-intervals, for example.

Iyer.

Hello adun - apologies for the delay in responding. Here are some comments in addition to bchever's responses.

We do have some prospects who use Terracotta to cluster and thereby simplify their code by avoiding RMI calls. However, currently we only support a LAN based deployment. And we have tested with a large number of clients -equivalent to the numbers you mention in terms of your application deployment footprint.

A WAN based deployment is on the roadmap - ofcourse, in this case, we will probably end up with an "optimistically synchronous" propagation model. i.e. ensure object mutations are persisted synchronously across TerracottaServers on a WAN, provided network latencies are a non-issue - else switch to asynchronous propagation.

Shortly sending you pricing information via email. WE could additionally do a call and discuss your use-case in greater detail and whether a phased-deployment might work for you (i.e. clients on a LAN initially) and then once the product supports it (clients on the WAN).

Thanks.

Hello:
Apologies for the delay in responding. Hope you've received the email with the license-key etc.

Yeah the test-case makes sense - there isn't anything else that one can do with regards to config-file settings, but for refactoring the app to define synchronization-boundaries appropriately - so as to minimize number of round-trips to the Terracotta server with regards to lock acquisition/release.

Another suggestion is to try 2.0.1 which is now publicly available for download - it features performance improvements (especially with regards to cluster-wide object creation, which your pseudo-code indicates your test does a lot of).

Thanks.

Hello ebagini:

Apologies for the delay in responding.

1.
If you could enumerate your H/W (cpu, ram), O/S and VM heap parameters, it would help us run comparable tests.

2.
As you mentioned, this test is an extreme case - so the closer the test is to your real app - the better it will advise you as to what the clustering overhead would be - In that it would be useful to account for the nature of operations to the Hashmap (how many gets versus puts) and what is the extent of contention on the puts/gets across nodes (i.e. simultaneous access on the same key across nodes).

3.
In this worst case test, there are no other "configuration" optimizations that immediately jump out (apart form the ones previously mentioned - such as the hashtable.put being already implicity synchronized, over and above the synchronized block around put in HelloWorld.java) - although upcoming versions feature improvements if the latency is due to object-creation and support for Java1.5 concurrent collection framework which do well compared to plain old Hashmaps with explicit synchronization around accessor methods.

4.
I will look into some of our internal benchmarks and find one that resembles this "extreme" case - and get back to you.

Best,
Iyer.

Hi Daniel:

Yes, collections (Hashmaps) are shareable, but subclasses of logically-managed classes are not (There might be something in future to address this). Therefore, as of now, we recommend that you substitute inheritance with delegation to get around this current limitation (i.e. if source-modification is acceptable, then you could instead of subclassing from Hashmap, have your class reference the Hashmap as a class-member and cluster that field).

Also a couple of other clarifications, based on some additional research:
1.
java.util Collections from JDK1.4 are supported - but currently several of the new Java1.5 collections such as ConcurrentHashMap aren't supported. They are on the near-road-map.
2.
With regards to question 5, about DSO running under Tomcat 5.5 - Tomcat5.5 isn't "officially" certified as mentioned earlier, but we did test out a few sample applications and DSO does work without issue.

Best,
Sreeni Iyer.

1) Why am I getting the above error?
Terracotta traverses the object-graph from the root downwards (since the whole object graph is what is clustered, expectedly). When doing so, it encountered the com.determine.definition.DefinitionSubMap class, which is a subclass of java.util.LinkedHashMap. LinkedHashMap is a logically-managed class and hence subclasses of it are not clusterable/portable (see below for what a logically-managed class is).

2) What is a logically-managed class?
Certain classes of objects are "logically managed" because DSO records and distributes the logical operations that were performed on them rather than changes to their internal structure.

Objects are logically managed either for performance reasons or because their internal structure is JVM-specific. for e.g. Classes that use hashed structures like java.util.Hashtable, java.util.~HashMap, or java.util.~HashSet are logically managed. The hashcodes that are used to create the internal structure of these classes are JVM-specific. If an object that has a structure based on JVM-specific hashcodes were physically managed, its structure on other JVMs in the DSO cluster would be incorrect, since the hashcodes would be different on the other JVMs.

3) Can LinkedHashMaps be shared?
Yes.

4) Can ConcurrentHashMaps be shared?
Yes.

5) Will Terracotta DSO run properly under Tomcat 5.5?
No. Terracotta DSO has been certified on Tomcat 5.0.28 (and WLS 8.x). Supporting Tomcat 5.5 is on the road-map - so it should be available soon.

6) Will Terracotta Sessions run properly under Tomcat 5.5?
No. Terracotta Sessions has been certified on Tomcat 5.0.28 (and WLS 8.x). Supporting Tomcat 5.5 is on the road-map - so it should be available soon.

Hope this helps. Please let us know if we can assist further via posts/email/voice etc.

Thanks,
Sreeni Iyer,
siyer@terracottatech.com,
415-4207825.

Hello:

Thanks for the posting. There seem to be several questions in here:

1.
The client-application greedily acquires locks from the Terracotta server. And flushes fine-grained object-mutations to the Terracotta server at a transaction-boundary that "naturally" occurs in Java - i.e. at the end of the synchronized block. From your test-code, we see that there is a tight loop and the synchronized block gets exercised for each iteration of the loop. This is perhaps an extreme-case - so if you test-case permits you, you could synchronize outside the loop (or in batches of certain sizes) - you would see much better numbers.

2.
Yes, the Terracotta Server is a hub - and is to be sized/scaled as a function of the clustered IO your application does. Currently there is only an Active/Passive configuration that is supported - although in the future, multiple active Terracotta servers could be deployed.

3.
The 4 client limit is only from a licensing perspective - technically there is no limit. Ofcourse, each client creates some overhead on the Terracotta server - but as mentioned earlier, the most important factors with regards to Terracotta server scalability is the amount of clustered-I/O and the extent of inter-node contention on any single object (since locking is fine-grained as well).

4.
We can send you by email a license-key (Ofcourse note that what you download could be used in a Dev environment - only caveat is that the Terracotta server will exit after 10 hours and will need to be restarted) and commercial/pricing information based on your application needs (Terracotta-Sessions and Terracotta-Spring is free for upto 4 nodes).

We will be happy to field a call and/or discuss further.
Thanks,
Sreeni Iyer