Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

See:

http://forums.terracotta.org/forums/posts/list/2218.page

Actually, this will work. In your tc-config.xml set the "host" parameter to be the public DNS name of your Terracotta server. (you need to have 9520 open to your developer console obviously). This way, that is what will be returned from the L2 to the developer console.

One caveat is that we usually recommend that your L1s (clients) pull their config from the L2 but if you did that in this situation you would have to pay for all traffic going in and out of the L2. Instead, copy the tc-config.xml to all the clients and set the "host" parameter to be the internal EC2 hostname of the Terracotta Server. It will be listening on all interfaces anyway. You will need to make sure your config files are all in sync of course.

With a low latency, decent bandwidth connection, it should work fine.

Cheers,

-Dave

Well, Apache and Tomcat will let you bind to different IPs for virtual hosting or for different protocols, not for failover. Tomcat clustering is multicast and therefore on a different IP than normal traffic but it's a completely different model. (I could never get their unicast clustering to work)

Regardless, the Terracotta server is not an app server or a web server so I don't think you can really compare the two.

When I said that it was messy, I wasn't talking about the fact that you wanted to separate functions on different subnets. I was thinking about a setup when you were using Network Active passive and you wanted to have the machines fail over in a fully redundant setup. Instead of configuring one network segment to be redundant on your NICs, you would now need 6 NICs all set to fail over, as well as the associated redundant switch setup and you would have to keep track of which segment the L1s were using when they need to failover to a passive TC server. Additionally, the heartbeating that the active and passives do might wind up being on a different network segment than the DSO or JMX traffic and you could get into a situation where one of the 3 segments fails and if it wasn't the heartbeating segment, the L2 would probably not fail over.

Just sounds messy to me. Doesn't mean it is not technically possible.

Cheers,

-Dave

Currently there is no way to specify a different address for each port, only to specify ports.

The funny thing is, they way to do what you want to accomplish would be to have TC bind to all interfaces and then just firewall off the ports to the specific interfaces you want, this would have to be done in the OS or on the network of course.

I can see why you would want to do what you are trying to accomplish even though it sounds very messy to configure from a network standpoint, if you really want this feature is suggest you open a JIRA.

Cheers,

-Dave

See the "bind" attribute under /tc:tc-config/servers/server

in the following document:
Configuration Guide

Cheers,

-Dave

Marks0,

Typically this would be done with a Windows Installer (MSI) file. You could have a completely unattended install (from a network share, etc.) if you used the msiexec "quiet" options. You could even control installation logging, etc. with Group Policy if you have Active Directory.

Of course we don't have an MSI installer for Terracotta at this time, but I'm sure you could cobble one together using the tarball or exe as a model. If this is really important to you, I suggest you file a JIRA request so that we can include it in future Terracotta releases.

Cheers,

-Dave

Something like this?

Code:

 $ cat terracotta 
 #!/bin/sh
 #
 #
 # chkconfig: 2345 55 25
 # description: Terracotta L2 server daemon                                                                                                                 
 #
 # shamelessy taken from the jsvc example script for Tomcat 
 # 
 JAVA_HOME=/usr/java/jdk1.5.0_09
 JAVA_OPTS="-server -Xms256m -Xmx256m -Dcom.sun.management.jmxremote"
 TC_HOME=/usr/local/terracotta
 DATA_DIR=/export1/tc-data
 CONFIG_FILE=tc-config.xml
 TC_OPTS="-Dtc.config=${DATA_DIR}/configs/${CONFIG_FILE}"
 LOG_DIR=logs-primary
 #LOG_DIR=logs-secondary
 CLASSPATH=\
 ${TC_HOME}/common/lib/tc.jar
 TC_USER=_tc
 TC_SERVER=l2a
 
 
 case "$1" in
   start)
     #
     # Start Terracotta
     #
     su - $TC_USER -c "${JAVA_HOME}/bin/java \
     $TC_OPTS \
     $JAVA_OPTS \
     -Dtc.server.name=$TC_SERVER \
     -Dtc.install-root=$TC_HOME \
     -classpath $CLASSPATH \
     com.tc.server.TCServerMain  > ${DATA_DIR}/${LOG_DIR}/terracotta.out  2>&1 &"
     ;;
 
   stop)
     #
     # Stop Terracotta
     #
     su - $TC_USER -c "${JAVA_HOME}/bin/java \
     $TC_OPTS \
     $JAVA_OPTS \
     -Dtc.install-root=$TC_HOME \
     -classpath $CLASSPATH \
     com.tc.admin.TCStop -n $TC_SERVER"
     ;;
 
   *)
     echo "Usage terracotta start/stop"
     exit 1;;
 esac

That worked fine in Teracotta 2.2.1 which was a long time ago. If it doesn't work let me know. I'm going to be using it for 2.6 so I'm going to have to update it if necessary anyway.

Also working towards a full LSB compliant script soon too.

Hope that helps.

-Dave

eluzcand,

Does it work now? If not, what browser are you using? Is JavaScript turned off?

Cheers,

-Dave

I think I know what's going on here. Confluence inexplicably dumped a bunch of permissions during the upgrade, though I hesitate to use that word.

I think I've fixed the docs. I'll keep poking around until I think everything is back to normal. Thanks for the heads up.

Peter,

We upgraded Confluence last night and, let's just say that the new version doesn't seem to be up to Atlassian's usual high standards.

I believe I've fixed the problem with your account. Let me know.

Cheers,

-Dave

The RMI server will return the address of whatever your hostname(1) is set to for clients connecting remotely.

An easy test (on Unix or Cygwin/CMD.exe):

telnet `hostname` 9520

If the first line says Trying 127... then your machine thinks that hostname is bound to a loopback address and you will not be able to remotely use the Admin console to monitor your Terracotta server. (but it will work fine running the Admin console to localhost on the same machine)

If you would like to resolve this, make sure that whatever name the hostname(1) command returns is resolvable to an external accessible IP address.

Hope that helps.

Q wrote:

Also the prod box is a Linux box (as you could guess it) and currently I run my java using jvsc. Do you have a recommended way to run Terracotta on a prod. box ?

Q,

You should have no problem running your Tomcat instances using jsvc. There used to be a problem in the past, but the fix is in our latest release.
(see http://jira.terracotta.org/jira/browse/CDV-284)

There is no need to run the Terracotta server itself with jsvc because it can be run clustered (on the same box if necessary) anyway. Just make sure you define the DATA directory to be the same for both instances (or checkout the new network-only setup). This can be done with NFS, SAN, or on the same box.

Here is an init script suitable for use on most Linux distributions for starting the Terracotta server.

Code:

 #!/bin/sh
 #
 #
 # chkconfig: 2345 55 25
 # description: Terracotta L2 server daemon                                                                                                                 
 # shamelessy taken from the jsvc example script for Tomcat 
 # 
 JAVA_HOME=/usr/java/jdk1.5.0_11
 JAVA_OPTS="-server -Xms256m -Xmx256m -Dcom.sun.management.jmxremote"
 TC_HOME=/usr/local/terracotta
 DATA_DIR=/export1/shares
 CONFIG_FILE=tc-config.xml
 TC_OPTS="-Dtc.config=${DATA_DIR}/configs/${CONFIG_FILE}"
 LOG_DIR=logs-primary
 #LOG_DIR=logs-secondary
 CLASSPATH=\
 ${TC_HOME}/common/lib/tc.jar
 TC_USER=_tc
 TC_SERVER=l2a
 
 
 case "$1" in
   start)
     #
     # Start Terracotta
     #
     su - $TC_USER -c "${JAVA_HOME}/bin/java \
     $TC_OPTS \
     $JAVA_OPTS \
     -Dtc.server.name=$TC_SERVER \
     -Dtc.install-root=$TC_HOME \
     -classpath $CLASSPATH \
     com.tc.server.TCServerMain  > ${DATA_DIR}/${LOG_DIR}/terracotta.out  2>&1 &"
     ;;
 
   stop)
     #
     # Stop Terracotta
     #
     su - $TC_USER -c "${JAVA_HOME}/bin/java \
     $TC_OPTS \
     $JAVA_OPTS \
     -Dtc.install-root=$TC_HOME \
     -classpath $CLASSPATH \
     com.tc.admin.TCStop -n $TC_SERVER"
     ;;
 
   *)
     echo "Usage $0 start/stop"
     exit 1;;
 esac

In this example, you should only need to change the $TC_SERVER and $LOG_DIR variables between the clustered Terracotta instances.

Cheers,

-Dave

rrudolph wrote:

Failed to add file 'labs/opendatagrid/datagrid/src/main/java/org/terracotta/datagrid/workmanager/ ': object of the same name already exists
*** Error (took 00:08.375)

Robert, it looks like there was a file with a blank name (i.e. a name like ' '). We were able to remove it so hopefully that clears up the problem with your checkout.

Let us know if you encounter any more problems. Thanks!

Cheers,

-Dave

No posts yet that test this out.

moved proxy protocol for apache