[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Messages posted by: bchever  XML
Profile for bchever -> Messages posted by bchever [17] Go to Page: 1, 2 Next 
Author Message
Sachin,

Our newest release of the Terracotta product suite , version 2.1, is online and available at:
https://www.terracottatech.com/downloads.jsp

These kits add support for additional classes including java.util.concurrent.ConcurrentHashMap.

Thanks for your patience.

Sachin,

Running Ubuntu 6.06 LTS (Dapper Drake) from the Live CD, I am able to run both the Terracotta server and all the included demos from the linux Sessions kit. All root objects are correctly shared.

Can you give me more information about what is failing in your environment, and the configuration file for the application?

Thanks!

An example of the config entry would be;

<dso> <-- at this level -->

<transient-fields>

<field-name>com.bea.wlw.netui.pageflow.FlowController._transientActionServlet</field-name>

</transient-fields>

</dso>
Hi Vidar,

Thank you for writing.

Remove the actual filename from the URL to the config file and all should work fine, e.g., instead of

-Dtc.config=http://localhost:9515/config/tc-config.xml

use

-Dtc.config=http://localhost:9515/config

Let us know if you have any other questions.

Sincerely,

Hi, Sachin.

Thanks for writing.

Yes, you are correct. As per page 25 of the TerracottaSessionsQuickStart.pdf;

"The java.util.concurrent package is not supported in this release of Terracotta. However, support for this package will be available in a future release of Terracotta."

Check back online for new releases. I will also see about getting you automatically notified when a new release is available that specifically addresses that package.

Sincerely,
Ian,

Thank you for writing.

There is an excellent example of a highly parallel application on our blog that deals with calculations of a Mandelbrot fractal. I think you'll find it very interesting. Please refer to;

http://blog.terracottatech.com/archive/2006/06/dso_mandelbrot.html#more

If you have any further questions during your evaluation, please feel free to write again.
Hi, Sriram.

I'll send you a private message to get contact info.

Regards,
Hi Sriram,

1. "So I have to keep track of a copy object which represents the old state (maintained at the time the last push was done to the C++ client) and then every time I want to push the changes to the C++ client just compare every field in the master object with the copy object and then just push only those changes."

There are a variety of ways to approach this. Along with #2, I will request our Professional Services team contact you to gather more specifics as to your requirements.

"3. Also I noticed that if the change was to a Object (like a java.util.Date) vs a primitive type like int/string, it sends us the new changed object (java.util.Date) in the change listener handler. Any insights to this."

The Java util classes are special cases that cannot be named locked, if that is what you tried. Instead of placing the lock on the actual add method of the java.util class, put the lock on the methods that are doing the calling.

Regards,


Sriram,

While there is nothing in the Terracotta products that will inform you of field-level changes, you could write something yourself that would keep track of those changes and then send the data to your client. Think of solving the problem in the same way you would when writing for a single VM. Just add fields that are populated when someting changes as a collection, and then clear that collection when the deltas are pushed to your C++ client.

With respect to operation on a WAN, let me explain further. There is nothing in our products that will prevent you from running on a WAN, but you need to understand that we do no security with our products, and, of course, there is nothing we can do about physical latency, i.e., if your network bandwidth is very large, DSO will work with no issues.

Sriram,

Thank you for writing.

A Terracotta WAN-based deployment is on the roadmap, but the current product is designed for a LAN environment.

I'll check with Engineering on whether there's a way to recognize the pushed deltas as you describe. What is the Windows client written in?

hooba,

Tomcat 5.5 wasn't in the scope of this release, but Development informs me that the Q3 release will most likely support it.

Thanks for writing,
adun,

I'ver asked our head of Sales Engineering, siyer, to get back to you to further discuss this.

As to your example, there is nothing in DSO that would prevent an application like the Shared Editor demo from performing well under the conditions you describe, however there is nothing in DSO that handles security, so access and latency via the variety of methods you mention will depend purely upon the network connection speed. We only distribute the deltas to objects, so DSO is not very chatty.

The reason I've asked siyer to discuss this with you is that I believe DSO could also be applied to your servers as well as your rich clients.

Thanks for your patience.
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,
pojoman,

Yes - "Terracotta Sessions for Tomcat" works and is supported on RHEL v4. x

It is free for up to 4 client-nodes (you will have to get a license-key from Terracotta Sales before going into production). In terms of next steps, you could:

1.
Simply download the Terracotta Enterprise Edition for RedHat: terracotta-2.0.0-rhel34-i686.tar.gz

2.
Assuming you have downloaded Terracotta Sessions for Windows and have tested out session failover on your desktop - then you'd have a copy of the configuration file (tc-config.xml). Copy that config file over to the Terracotta home directory (that you downloaded in step 1) and use that.

3.
If that config file is not available, then you will have to create the tc-config.xml file appropriately.

4.
Note that you will have to modify your Tomcat startup scripts to enable DSO. (You could refer to the start-tomcat-9081.bat script that comes with the Windows build of Terracotta Sessions) and do what it does -- it just sets some environment variables.

The TomcatSRGuide.pdf in the docs directory under the install from (1) is a great resource, or you can always ask questions here.

Regards,
ebagini,

In addition to the information you've received from SIyer, our development team took a look at your example and they have some suggestions;
***********
There are several performance bottlenecks built into your code.

For example look at the following fragment of HelloWorld.java

for (int i = inizioC; i < fineC; i++) {
if (key.equals("N")) {
//String l=pippo1[i];
synchronized (pippo1[i]) { // **** 1
hellos.put(pippo1[i], new InfoHash("pippo" // **** 2
+ hellos.size(), "pluto" + hellos.size()));
}
....

This uses a fine grained lock to modify the collection. The trouble there is that the hellos collection is a Hashtable which is synchronized implicitly and autolocked by DSO.

Also it is not understood why it is needed to lock on the key value when doing insert. And the value of pippo1[i] can change between lines 1 and 2 below.

It should give you a performance boost if those puts are batched up into a temporary Map and then inserted using hellos.putAll(batchedHellos).

Your shown code is only adding new elements into collection. So, it does not really show Terracotta advantages for field-level incremental changes. I'd suggest to add the following scenario:

1. insert all elements into the distributed collection
2. randomly choose a key from that collection
3. within synchronized block on instance of that key
4. retrieve collection element for that key
5. modify retrieved instance
6. repeat steps 2-5 N times

To make that even more realistic, your test could use Map of Lists of InfoHash objects and randomly choose and update several infohash elements from list instance for given key.
***********

So, as SIyer suggested, we are available to discuss further via here or a call if you like.

Regards,
 
Profile for bchever -> Messages posted by bchever [17] Go to Page: 1, 2 Next 
Go to:   
Powered by JForum 2.1.7 © JForum Team