Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi All,

I have downloaded the TerraCotta for Spring, I want to execute the demo application (Events and JMX) in the distributed mode i.e. TerraCotta Server in one box and Tomcat-1, Tomcat-2 in different box. Where should I look for the changes in IP/port so that the client nodes can communicate to the TerraCotta Server.

However this demo applications are running fine in the same box.

Expecting the positive reply.

Thanks
Raj

Hi Raj,

With a single Terracotta server, which appears to fit the scenario you are desribing, and an arbitrary number of clients, you don't have to worry about ports on the Terracotta server side -- just start it normally. Then in the client configuration, you only need to supply the values for the standard name and host attributes of the server tag. The clients will then connect to the Terracotta server using the default Terracotta server ports, which will be correct.

If there's something I don't understand about your scenario, please let me know, and I'll be happy to get back to you quickly.

Hi raj,

Just in case you're looking at running two Terracotta servers -- and for the benefit of other readers -- let me clarify how to run two Terracotta servers and n number of clients.

The key to using an active/passive pair is configuring both servers for persistent mode and making sure both point to the same location for the server data. In addition, the clients should have a comma-separated list of
the servers they can reach configured as a comma-separated list of urls that point to the TC servers in the Terracotta startup arguments for the client. One or both of those configuration items would need to be amiss for
it not to work as expected.

If you look at the reference copy of the tc-config.xml in the distributions, you'll see two servers defined. You would want to emulate that configuration. Specifically, have a look at the snippet from that file below. Each server should have a unique name and an accurate host name. The DSO ports should of course be different for each. Finally, the data storage mode should be persistent (as in the example) and each server should point to the same path for its data storage (e.g. SAN, NFS, other shared disk approach).

From the client perspective, you want to use to -Dtc.config= argument with each client, and supply a comma-separated list of servers to reach -- for example,

-Dtc.config=http://server01:9510/config,http://server02:9511/config

where you would have used 9511 for the DSO port for the second server in the tc-config file. This is the standard production configuration, where the tc-config.xml file is loaded by the server(s), and the clients connect via the DSO port of the respective servers to retrieve the configuration information. Again, here is the snippet:

<servers>


<server name="apple" host="artichoke">


<data>/opt/terracottaserver-data</data>


<logs>/opt/terracotta/server-logs</logs>


<dso-port>9510</dso-port>


<dso>


<client-reconnect-window>120</client-reconnect-window>


<persistence>

<mode>permanent-store</mode>
</persistence>

Hello Raj,

For further clarification, you can follow the following steps to run the spring demos on multiple tomcat instances clustered through Terracotta Srping:

Firstly, install the same version of Terracotta ditribution on all the machines that you wish to cluster as well as on the machine that will host the Terracotta server.

Before you start, please make sure that the TC_INSTALL_DIR and TC_JAVA_HOME environment variables are set. You should set TC_INSTALL_DIR to the Terracotta installation root directory (the directory containing the 'spring' directory). You should set the TC_JAVA_HOME environment variable to your JAVA_HOME (if set) or to the appropriate JDK/JRE. It is recommended that you use the same JRE/JDK for Tomcat as you define in TC_JAVA_HOME.

1. Start the Terracotta server by passing the appropriate tc-config.xml on some machine (say host1).

Code:

 %TC_INSTALL_DIR%\spring\bin\start-tc-server.bat -f tc-config.xml

You should find the tc-config.xml files for the demos in their appropriate directories.

2. Start the individual tomcat nodes using the following script.

Code:

 call "%TC_INSTALL_DIR%\spring\bin\dso-env.bat" -q tc_server_hostname:9510
 set java_opts=%tc_java_opts% -Dcom.sun.management.jmxremote
 set jpda_transport=dt_socket
 set jpda_address=localhost:8001
 call %CATALINA_HOME%\bin\catalina.bat run

You will need to replace the tc_server_hostname in the above script with the hostname of the machine on which you started the Terracotta Server in step 1 (e.g. host1 or localhost etc.).

Look in the catalina logs for something like this:

Code:

 Using CATALINA_BASE:   C:\tomcat5.0.28
 Using CATALINA_HOME:   C:\tomcat5.0.28
 Using CATALINA_TMPDIR: C:\tomcat5.0.28\temp
 Using JAVA_HOME:       C:\jdk1.5.0_08
 2007-02-12 10:44:38,247 INFO - Terracotta, version 2.2.0 as of 20070109-190156.
 2007-02-12 10:44:39,982 INFO - Configuration loaded from the server at 'localhost:9510'.
 2007-02-12 10:44:40,075 INFO - Log file: 'C:\Documents and Settings\kbhasin\terracotta\events\client-logs\terracotta-client.log'.

The line 'Terracotta, version 2.2.0 as of 20070109-190156' suggests that the Terracotta modules were successfully started with your app.

Next, you can connect to the TC Server through the tc-admin (in %TC_INSTALL_DIR%\spring\bin\tc-admin.bat) tool and see if you see the clients and the roots (look in the tree like UI on the left pane). If you do, the application is clustered.

Let us know how it goes.

Regards,
Kunal Bhasin.

Also,

If you get the following error at any point:

Code:

 The DSO boot JAR you need for this platform does not exist. You may need to run the 'make-boot-jar' script

please follow this link: http://wiki.terracotta.org/confluence/display/wiki/Troubleshooting+Guide#TroubleshootingGuide-Iamgettinga%22TheDSObootJARyouneedforthisplatformdoesnotexist.Youmayneedtorunthe%27makebootjar%27script%22messagehow%3F. where you will find instructions to create the boot-jar for your environment.

Regards,
Kunal.

Hi Friends,
Thanks a lot for your valuable suggestions. I am able to execute in distributed mode without fail. Actually, my requirement is that, I have struts application running which is sending data to other application using JMS, I want to replace the JMS queue funtionality using Terracotta, which gives me additional functionality with clustering. Please share your thoughts on this. Probably I am giving my best time now to formulalize the solution using Terracotta. I may bother you guys time to time till I reach to the solution.

Hello Raj,

What are you actually trying to share (through JMS queues) within the Struts Framework across multiple nodes? In an ideal scenario, it is sufficient to share the Model (Business POJOs) and not the View (JSPs/ActionForms) or the Controller (ActionServlets, Actions).

You can utilize Terracotta DSO (for sharing business POJOs) and Terracotta Sessions for sharing HttpSession objects being maintained by the container (e.g. tomcat), as the Struts framework utilizes the HttpSession to store user state.

In a nutshell, you would not need any messaging API or messaging specific infrastructure/code to share the Struts state with Terracotta. Unlike JMS, the shared objects would not need to implent java.io.Serializable. Each application node would access the Struts state information as they would in a single JVM (as though they were different threads in a single JVM).

It would definitely be helpful to get some more information about the kind of data your Struts application is sending to other application instances using JMS.

You will find this Webinar on Clustering Struts with Terracotta hosted by Don Brown (of Struts) and Jonas Boner (of Terracotta) very useful - http://www.terracottatech.com/webinar_struts.shtml (you can view the recorded event).

Regards,
Kunal Bhasin.