In this blog post I describe how to set up a cluster node with an embedded Jetty Server inside Equinox.

Basically I followed the instructions available at the Jetty Wiki page Session Clustering Using a Database [1].

There are two Jetty configuration files involved:

• /etc/jetty.xml defining a JDBCSessionIdManager
• /WEB-INF/jetty-web.xml defining a JDBCSessionManager

The main jetty.xml resides in the folder etc of the jetty.home.bundle which itself is a fragment of org.eclipse.jetty.osgi.boot. The jetty.osgi.boot bundle is provided by the Jetty team and is responsible for bootstrapping Jetty in an OSGi environment.

The main configuration file contains the JDBCSessionIdManager definition using a H2 database:

 <Set name="sessionIdManager">
  <New id="jdbcidmgr" class="org.eclipse.jetty.server.session.JDBCSessionIdManager">
    <Arg>
      <Ref id="Server" />
    </Arg>
    <Set name="workerName">
      <SystemProperty name="worker.name" default="primary" />
    </Set>
    <Call name="setDriverInfo">
      <Arg>org.h2.Driver</Arg>
      <Arg>jdbc:h2:tcp://localhost:9101/sessions</Arg>
    </Call>
    <Set name="scavengeInterval">60</Set>
  </New>
</Set>
<Call name="setAttribute">
  <Arg>jdbcIdMgr</Arg>
  <Arg>
    <Ref id="jdbcidmgr" />
  </Arg>
</Call>

Note: To reuse the configuration in multiple cluster nodes I use a SystemProperty tag to give every node a unique “worker.name”. The database configuration is hardwired to a local H2 database.

With additional system properties I can tell the Jetty bootstrapper where to look for the global Jetty configuration and which port the Jetty instance should bind to:

-Dworker.name=primary
-Djetty.port=18081
-Djetty.home.bundle=com.eclipsesource.cluster.jetty.home.bundle

To enable the Jetty server to load the H2 database drivers I added a dynamic import directive via the fragment org.eclipse.jetty.serverdynamic.import:

Fragment-Host: org.eclipse.jetty.server;bundle-version="7.4.2"
DynamicImport-Package: *

The web application specific configuration /WEB-INF/jetty-web.xml is located in the web bundle, com.eclipsesource.cluster.jetty.demo.webbundle. This configuration file contains the JDBCSessionManager definition.

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
  <Get name="server">
    <Get id="jdbcIdMgr" name="sessionIdManager" />
  </Get>
  <Set name="sessionHandler">
    <New class="org.eclipse.jetty.server.session.SessionHandler">
      <Arg>
        <New class="org.eclipse.jetty.server.session.JDBCSessionManager">
          <Set name="idManager">
            <Ref id="jdbcIdMgr" />
          </Set>
        </New>
      </Arg>
    </New>
  </Set>
</Configure>

Note: “jdbcIdMgr” is a Reference to the jetty.xml from jetty.home.bundle.

If you want to try it out yourself, the code is available at GitHUB [2].

Note: The bundle com.eclipsesource.cluster.h2 contains an Eclipse launch configuration to start a local H2 database which is needed to run the example.

[1] http://wiki.eclipse.org/Jetty/Feature/Session_Clustering_Using_a_Database
[2] https://github.com/eclipsesource/com.eclipsesource.cluster

Tags: cluster, jetty, OSGi

First, a bit of news for developers following the Virgo project:  The release day for Virgo Maya is getting closer[1] with the successful RC1 release a few weeks ago.

Meantime, in this blog post I’ll describe another way of running RWT (the RAP Widget Tookit) based applications on the Virgo Jetty Server. I want to use Virgo’s RFC66 support to deploy web applications in OSGi.
The RFC66 Web Container specification creates an open standard that enables developers to deploy WAR files on OSGi. With a few modifications (see below) it is possible to deploy an RWT standalone application into an RFC66 container like Virgo.

Note: In addition to using the HttpService described here[2] with RAP 1.5 you can register RWT directly with an OSGi HTTP service. We’ll describe this in a follow-up post.

To extend Virgo you need to:

1. Get a Virgo Jetty Server Release Candidate[3].
2. Install our extension of Virgo as suggested here[4] into /repository/ext.

Note: You can get a patched RWT bundle here that  supports RFC66 deployment of RWT applications and the plan here. The Virgo deployment plan describes all bundles needed to support RWT applications in Virgo.

Copy the two downloaded artifacts into repository/ext:

~virgo-jetty-server> ls -1 repository/ext/*rwt*
repository/ext/org.eclipse.rap.rwt-1.5.0.plan
repository/ext/org.eclipse.rap.rwt_1.5.0.201108081102.jar

Next I added our RWT extension to the initial Virgo artifacts. This is configured in
config/org.eclipse.virgo.kernel.userregion.properties. We simply add our plan:

initialArtifacts=repository:plan/org.eclipse.virgo.kernel.userregion.springdm,\
         repository:plan/org.eclipse.virgo.jetty.web,\
         repository:plan/org.eclipse.rap.rwt

That’s all that has to be done on the Virgo side. If you start Virgo Jetty Server you should
see the extension starting properly:

[2011-08-08 12:23:45.909] system-artifacts              Installing plan 'org.eclipse.rap.rwt' version '1.5.0'.
[2011-08-08 12:23:47.626] system-artifacts              Installing bundle 'org.eclipse.rap.rwt' version '1.5.0.201108081102'.
[2011-08-08 12:23:47.663] system-artifacts              Installed bundle 'org.eclipse.rap.rwt' version '1.5.0.201108081102'.
[2011-08-08 12:23:47.665] system-artifacts              Installed plan 'org.eclipse.rap.rwt' version '1.5.0'.
[2011-08-08 12:23:47.725] system-artifacts              Starting plan 'org.eclipse.rap.rwt' version '1.5.0'.
[2011-08-08 12:23:47.729] system-artifacts              Starting bundle 'org.eclipse.rap.rwt' version '1.5.0.201108081102'.
[2011-08-08 12:23:47.734] start-signalling-2            Started bundle 'org.eclipse.rap.rwt' version '1.5.0.201108081102'.
[2011-08-08 12:23:47.737] start-signalling-2            Started plan 'org.eclipse.rap.rwt' version '1.5.0'.

Because an RWT standalone application doesn’t know about OSGi classloading, I thought that one solution might be to use buddy classloading. First, I enabled buddy classloading in org.eclipse.rap.rwt.

Bundle-SymbolicName: org.eclipse.rap.rwt
Bundle-Version: 1.5.0.qualifier
...
Eclipse-BuddyPolicy: registered

Then I registered the RWT application com.eclipsesource.sovereign.swt.layout.web as a buddy:

Bundle-SymbolicName: com.eclipsesource.sovereign.swt.dialog
...
Require-Bundle:
 org.eclipse.rap.rwt
Export-Package: com.eclipsesource.sovereign.swt.dialog
Eclipse-RegisterBuddy: org.eclipse.rap.rwt
Web-ContextPath: /rap

Note: In the MANIFEST.MF of the web bundle we specified the context path to “/rap”.

Next I setup the RAP web application. The web.xml almost looks like that of a standard RWT standalone application. For more details please go to the RAP Wiki [5]:

<context-param>
  <param-name>org.eclipse.rwt.entryPoints</param-name>
  <param-value>com.eclipsesource.sovereign.swt.dialog.SwtDialogEntryPoint</param-value>
</context-param>
<listener>
  <listener-class>org.eclipse.rwt.internal.engine.RWTServletContextListener</listener-class>
</listener>
 
<servlet>
  <servlet-name>rwtDelegate</servlet-name>
  <servlet-class>org.eclipse.rwt.internal.engine.RWTDelegate</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>rwtDelegate</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>

You’ll see an additional section for the RWT resources:

<servlet>
  <servlet-name>rwtResources</servlet-name>
  <servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>rwtResources</servlet-name>
  <url-pattern>/rwt-resources/*</url-pattern>
</servlet-mapping>

Now I was ready to deploy my RAP application. I simply copied the webbundle into Virgo’s pickup folder.

Note: You can get the sample RAP webbundle here.

[2011-08-08 12:25:34.421] fs-watcher                    Hot deployer processing 'CREATED' event for file 'com.eclipsesource.sovereign.swt.dialog_0.1.0.201108081127.jar'.
[2011-08-08 12:25:34.476] fs-watcher                    Installing bundle 'com.eclipsesource.sovereign.swt.dialog' version '0.1.0.201108081127'.
[2011-08-08 12:25:34.486] fs-watcher                    Installed bundle 'com.eclipsesource.sovereign.swt.dialog' version '0.1.0.201108081127'.
[2011-08-08 12:25:34.492] fs-watcher                    Starting bundle 'com.eclipsesource.sovereign.swt.dialog' version '0.1.0.201108081127'.
[2011-08-08 12:25:34.494] start-signalling-3            Started bundle 'com.eclipsesource.sovereign.swt.dialog' version '0.1.0.201108081127'.

And the application is available at localhost:8080/rap

[1] Virgo 3.0 (Maya) Release Candidate 1
[2] Running RAP on Virgo
[3] Milestone Downloads
[4] Extending Virgo with a HttpService
[5] How do I use an RWT standalone application in Tomcat

Tags: OSGi, rap, rwt, virgo

I just pushed a template for creating AspectJ applications with Tycho and will give you a quick tour of it here. You’ll find the template on github [1]

The template contains four infrastructure projects. One defines an OSGi command to calculate faculties and another contains an aspect to measure the duration of the calculation.

Let’s take a closer look. com.eclipsesource.weaving.demo.releng contains the Maven parent pom.xml file which defines the modules of the application:

<groupId>com.eclipsesource.sandbox.weaving.demo</groupId>
<artifactId>com.eclipsesource.sandbox.weaving.demo.parent</artifactId>
<version>0.1.0-SNAPSHOT</version>
 
<packaging>pom</packaging>
...
<modules>
 <module>../platform</module>
 
 <module>../weaving.demo.chronometry</module>
 <module>../weaving.demo.faculty</module>
 <module>../weaving.demo.feature</module>
 
 <module>../repository</module>
</modules>

com.eclipsesource.weaving.demo.platform – contains the target definition

com.eclipsesource.weaving.demo.feature – defines the application scope

com.eclipsesource.weaving.demo.repository contains the product definition. One very important VM argument, almost hidden from the debug arguments, registers the framework weaving extension:

-Dosgi.framework.extensions=org.eclipse.equinox.weaving.hook

The weaving service has to be started early.

As well as the four infrastructure projects, the template contains the application code:
com.eclipsesource.weaving.demo.faculty – provides an OSGi console command to calculate faculty.

public class FacultyCommandProvider implements CommandProvider {
 
  public void _faculty(CommandInterpreter ci) {
    String argument = ci.nextArgument();
    int argumentAsInteger = Integer.valueOf(argument).intValue();
    System.out.println("Faculty of " + argumentAsInteger + " is "
          + recur(argumentAsInteger));
  }
...

com.eclipsesource.weaving.demo.chronometry – contains the Aspect to measure the faculty execution time.

public aspect CommandProviderChronometer {
  void around(CommandInterpreter ci):
        execution(void CommandProvider+._faculty(CommandInterpreter))
          && args(ci) {
    long start = System.nanoTime();
    proceed(ci);
    long duration = System.nanoTime() - start;
    System.out.println("Result calculated in " + (duration / 1000) + " micro seconds");
  }
}

The following snippet from the project’s pom.xml file tells Tycho to use the aspectj compiler:

...
<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>aspectj-maven-plugin</artifactId>
      <version>1.3.1</version>
      <configuration>
        <verbose>true</verbose>
        <complianceLevel>1.5</complianceLevel>
     </configuration>
     <executions>
       <execution>
        <goals>
          <goal>compile</goal>
        </goals>
      </execution>
    </executions>
 </plugin>
 </plugins>
</build>
...

We build the application the Tycho way, from the command line with Maven 3.x:

> cd releng
> mvn package
...
[INFO] --- tycho-p2-director-plugin:0.12.0:archive-products (archive-products) @ com.eclipsesource.sandbox.weaving.demo.repository ---
[INFO] Building zip: .../weaving.demo_...-macosx.cocoa.x86_64.zip
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] com.es..weaving.demo.parent ..... SUCCESS [0.002s]
[INFO] com.es..weaving.demo.platform ... SUCCESS [0.269s]
[INFO] com.es..weaving.demo.faculty .... SUCCESS [1.995s]
[INFO] com.es..weaving.demo.chronometry  SUCCESS [0.482s]
[INFO] com.es..weaving.demo.feature .... SUCCESS [0.533s]
[INFO] com.es..weaving.demo.repository . SUCCESS [7.262s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

We can now unzip the artifact and launch the application:

> unzip weaving.demo_selfcontained-macosx.cocoa.x86_64.zip
> Eclipse.app/Contents/MacOS/eclipse

The following output shows that weaving was successful:

osgi> [org.eclipse.equinox.weaving.aspectj] info Starting AspectJ weaving service ...
...
[com.eclipsesource.weaving.demo.faculty] info register aspect com.es..CommandProviderChronometer
[org.eclipse.equinox.weaving.aspectj] info weaving bundle 'com.eclipsesource.weaving.demo.faculty'
[com.eclipsesource.weaving.demo.faculty] weaveinfo Join point 'method-execution(void com.es..FacultyCommandProvider._faculty(org.eclipse..CommandInterpreter))'
in Type 'com.es..FacultyCommandProvider' (FacultyCommandProvider.java:9)
advised by around advice from 'com.es..CommandProviderChronometer' (CommandProviderChronometer.aj:8)

Running the OSGi console command shows the measurement in action:

osgi> faculty 23
Faculty of 23 is 862453760
Result calculated in 1165 micro seconds

[1] https://github.com/eclipsesource/com.eclipsesource.tycho.aspectj.demo

Tags: aspectj, OSGi, tycho

Only a few days remain until EclipseCon 2011 starts. We are eagerly anticipating our chance to present you an introduction to our ongoing research project Sovereign.

The talk, “Migrating Java Threads to Improve Availability of Web Applications” demonstrates an innovative solution how RAP applications can run on a cluster for failsafe operation.

After our first test run (75 minutes for a 20 minutes talk) we decided to put some of the technical details on our brand new Sovereign homepage, where you can have a look at them in a spare minute. This way we can stick with our two demonstrations that will provide you a better picture of what Sovereign really is about than just low level details.

Markus and Johannes hope to see you there…

Tags: clustering, rap, sovereign

Thanks for participating in our survey “How do you run your RAP application today?“  The poll was online for one and a half months.  During this period we collected around 150 replies.

With positive replies from more than 60% of the respondents, war deployment is the most commonly used deployment scenario. Most are running on Tomcat/Jetty (39%). Every fourth installation of a RAP application is run on plain Equinox with embedded Jetty (26%).  Following quite far behind there are a few installations that are running RAP on a Virgo Web Server/Virgo Kernel and some home-brewed launch scripts.

At EclipseCon 2011, the Sovereign Project will present the latest on our ongoing research on clustering RAP in the talk, “Migrating Java Threads to Improve Availability of Web Applications“.

Currently we are targeting plain Equinox and Virgo Kernel installations. As a result of this poll, we’ll stretch our feelers to war deployment and the Virgo Web Server. It’s great to have your input for the project.

Tags: rap, sovereign, war deployment

Hi,

We’d like to know more about RAP in the wild. Please take a moment and answer the question that follows below. We will publish the results of this anonymous poll later on this blog, and we’ll use them to influence the direction of the research work of the Sovereign project.

Thanks for your time.

How do you run your RAP application today?

War deployment in a plain Servlet Container (Tomcat, Jetty)

War deployment in an application server (JBoss, Glassfish, …)

Virgo Kernel with additional Jetty

Virgo Web Server

PaxRunner

PaxRunner with war profile

Standalone Equinox with embedded Jetty

Command Line / homebrewed launch script

View ResultsVote Now

Create an online survey quiz or web poll

War deployment in a plain Servlet Container (Tomcat, Jetty)0%

War deployment in an application server (JBoss, Glassfish, …)0%

Virgo Kernel with additional Jetty0%

Virgo Web Server0%

PaxRunner0%

PaxRunner with war profile0%

Standalone Equinox with embedded Jetty0%

Command Line / homebrewed launch script0%

Other: (Please specify)0%

Create an online survey quiz or web poll

Tags: equinox, jetty, paxrunner, rap, sovereign, tomcat, war deployment

You used to have just two options for deploying a RAP application:

1. Packing your application into a WAR archive and deploying it on a standard servlet container such as Tomcat, or
2. Embedding the Application and a servlet container in a standalone Equinox instance.

Now you have a third option because RAP runs on Virgo! Virgo is a full-featured OSGi based application server and is one of the shining new stars of the Eclipse ecosystem. Previously, we weren’t able to deploy RAP applications on this server because we were blocked by bugs relating to split packages. However, over the last few weeks we worked together with the Virgo team to fix these issues and we are happy to report success.

Here are the steps we used to deploy RAP on Virgo. We know the process can be improved, but just to give you an idea of how it works, try the following:

1. Download Virgo Kernel[1] (2.1.0.RELEASE) and unpack the downloaded archive to a directory (We’ll use ${KERNEL_HOME} in this post).
2. Download the RAP Runtime[2] (1.3.x) and extract the contents of the plugin folder into the Virgo repository:
   unzip rap-runtime-1.3.1-R-20100915-2301.zip "eclipse/plugins/*.jar" -x "eclipse/plugins/*.source_*" -d /tmp
cp /tmp/eclipse/plugins/*.jar ${KERNEL_HOME}/repository/usr
3. (via OSGi console) Enable the OSGi console by configuring the User Region, Virgo’s subsystem for managing user applications.
   Open $SERVER_HOME/config/org.eclipse.virgo.kernel.userregion.properties and uncomment the osgi.console property: 

   ...
# osgi console support
osgi.console=2401


4. (optional) Change the default port of the OSGi HttpServiceexport JAVA_OPTS=-Dorg.osgi.service.http.port=10081

5. Start the Virgo Kernel
   ./startup.sh
 

   ...
[2010-10-28 11:43:23.767] Thread-2 User region ready.


6. Virgo Plans[3] encapsulate the artifacts of an application as a single unit. We’ve created a rap-demo.plan for you. You can inspect and download from here:
   rap-demo.plan
7. Now add the downloaded rap-demo.plan to the pickup folder ${KERNEL_HOME}/pickup. You will see the following deployment:
   [2010-10-28 11:04:02.113] fs-watcher <HD0001I> Hot deployer processing 'MODIFIED' event for file 'virgo-rap-demo.plan'.
[2010-10-28 11:04:02.161] fs-watcher <DE0000I> Installing plan 'virgo-rap-demo' version '1.3.1'.
[2010-10-28 11:04:02.187] fs-watcher <DE0000I> Installing plan 'vigo-equinox-extensions' version '3.6.1'.
[2010-10-28 11:04:02.209] fs-watcher <DE0000I> Installing plan 'virgo-rap-extensions' version '1.3.1'.
[2010-10-28 11:04:06.397] fs-watcher <DE0000I> Installing bundle 'org.eclipse.rap.demo' version '1.3.1.20100915-2301'.
[2010-10-28 11:04:06.966] fs-watcher <DE0000I> Installing bundle 'org.eclipse.osgi.services' version '3.2.100.v20100503'.
[2010-10-28 11:04:07.473] fs-watcher <DE0000I> Installing bundle 'org.eclipse.equinox.preferences' version '3.3.0.v20100503'.
[2010-10-28 11:04:07.775] fs-watcher <DE0000I> Installing bundle 'org.eclipse.equinox.app' version '1.3.1.R36x_v20100803'.
[2010-10-28 11:04:08.440] fs-watcher <DE0000I> Installing bundle 'org.eclipse.core.commands' version '3.6.0.I20100512-1500'.
...
[2010-10-28 11:05:45.458] fs-watcher <DE0004I> Starting bundle 'org.eclipse.rap.demo' version '1.3.1.20100915-2301'.
[2010-10-28 11:05:45.464] start-signalling-1 <DE0005I> Started bundle 'org.eclipse.rap.demo' version '1.3.1.20100915-2301'.

8. (via OSGi console) You can now start the OSGi HttpService using the Equinox Console and start the HttpService manually user@hostname:~/> telnet localhost 2401
   Trying ::1…
   Connected to localhost.
   Escape character is ‘^]’. 

   osgi> ss
   …
   33 <<LAZY>> org.eclipse.equinox.http.jetty_2.0.0.v20100503
   …

   osgi> start 33

9. And, finally point your browser to http://localhost:10081/rap?startup=controls …

That’s it – RAP is now running on Virgo. We want to improve this process over time and, hope that you will share some ideas with us on how to do this. You can respond to this blog or ping us on the RAP newsgroup.

PS -One alternative solution to starting the HttpService via the OSGi console is adding an autostart bundle to the plan:

1. (via autostart) Download the org.equinoxosgi.core.autostart bundle as used at equinoxosgi.org – starts all lazy bundles in the OSGi container.
2. (via autostart) Add the autostart bundle to the downloaded plan before dropping into the pickup folder. <artifact type="bundle" name="org.equinoxosgi.core.autostart" version="[1.0.0, 2.0.0)" />


[1] Virgo Downloads - http://www.eclipse.org/virgo/download/

[2] RAP Runtime - http://eclipse.org/rap/downloads/1.3/

[3] Virgo Documentation - Programmer Guide 4.3 Creating Plans - http://www.eclipse.org/virgo/documentation/

[4] Virgo Documentation - User Guide 11.1. Configuring the Virgo Kernel and User Region - http://www.eclipse.org/virgo/documentation/

Tags: indigo, rap, virgo

Terracotta is a transparent clustering service that allows multiple Java processes on different JVMs to work together using pure objects and threading logic. Here’s how you can use it with Equinox.

Prerequisites: An installation of Java 1.6.0u20 or later (Java SE Downloads) and Terracotta (Open Source Option) Terracotta Download..

Install the downloaded Terracotta:

> tar xvfz terracotta-3.3.0.tar.gz
> export TC_HOME=/opt/tools/terracotta-3.3.0

We wan’t Terracotta to integrate with Equinox. This is where Terracotta Integration Modules come into play:

Terracotta Integration Modules (TIMs) are sets of configuration elements and supporting Java classes packaged together as a single, includable module within the Terracotta configuration. A TIM allows you to integrate Terracotta DSO with the framework or platform that your application is based on.[1]

Let’s look how to include the TIM for Equinox 3.5.1 in the Terracotta configuration file $TC_CONFIG_HOME/tc-config.xml:

We create our own tc-config.xml in $TC_CONFIG_HOME based on a Terracotta sample configuration $TC_HOME/platform/samples/tc-config.xml. Add this snippet to the basic sample config:

Use the Terracotta helper tim-get.sh to install the TIM locally…

> $TC_HOME/bin/tim-get.sh install tim-equinox-3.5.1 1.2.0
Terracotta 3.3.0, as of 20100716-150712 (Revision 15922 by cruise@su10mo5 from 3.3)
 
Installing tim-equinox-3.5.1 1.2.0...
   INSTALLED: tim-equinox-3.5.1 1.2.0 - Ok

Done. (Make sure to update your tc-config.xml with the new/updated version if necessary)
Now that we’ve configured the Equinox integration it’s time to tell Terracotta about our counter, a POJO:

public class Counter {
 
	private AtomicInteger counter;
 
	public int inc() {
		return counter.incrementAndGet();
	}
 
	public int getCurrentCounter() {
		return counter.intValue();
	}
}

Our Terracotta ‘application’ configuration holds the simple root object (graph) : A “root” is the top of a clustered object graph as declared in the Terracotta configuration.[2]

 
      com.eclipsesource.sovereign.terracotta.counter..*
 
      com.eclipsesource.sovereign.terracotta.counter.Counter.counter

Last we need a so called Terracotta “boot JAR”:

Some classes, however, are loaded too early in the lifecycle of the JVM for Terracotta to hook into their loading process. These are classes that are loaded by the boot classloader. Such classes cannot be instrumented at classload time, but must be pre-instrumented and placed in a special JAR file that is then prepended to the boot classpath.[2]

This is done with a Non-Standard Option of the JVM [3]

-Xbootclasspath/p:${TC_CONFIG_HOME}/boot JAR.jar

> $TC_HOME/platform/bin/make-boot-jar.sh -f $TC_CONFIG_HOME/tc-config.xml
2010-09-09 15:11:15,446 INFO - Terracotta 3.3.0, as ...
...
2010-09-09 15:11:27,456 INFO - Successfully created boot JAR file at ...
> cp $TC_HOME/lib/dso-boot/dso-boot*jar $TC_CONFIG_HOME

Enough installation and configuration. Engage! We need a running Terracotta server instance.

Terracotta server instances together form a Terracotta server array, which is the heart of a Terracotta cluster. Each Terracotta server instance performs two basic functions:[2]

• Cluster-wide thread coordination and lock management
• Clustered object data management and storage

> $TC_HOME/bin/start-tc-server.sh -f $TC_CONFIG_HOME/tc-config.xml
2010-09-09 15:34:42,370 INFO - Terracotta 3.3.0, as of ...
2010-09-09 15:34:55,915 INFO - Terracotta Server instance has started up... successfully, and is now ready for work.

What’s a server without a client? We fire up the Equinox client with Pax Runner with some additional JAVA_OPTS:

> export JAVA_OPTS=-Dtc.install-root=${TC_HOME} -Dtc.config=${TC_CONFIG_HOME}/tc-config.xml -Xbootclasspath/p:${TC_CONFIG_HOME}/dso-boot-hotspot_linux_160_21.jar

One configuration file contains our counter OSGi bundle etc/counter-demo.pax:

mvn:com.eclipsesource.sovereign/terracotta.counter/0.1.0-SNAPSHOT

The second specifies platform, version, inProcess executor, bootDelegation, …

--platform=equinox
--version=3.5.1
--executor=inProcess
--bootDelegation=sun.*,com.sun.*,javax.xml.*,javax.xml.transform.*,...
--systemPackages=javax.naming, javax.naming.directory, javax.naming.spi, ...

>$PAX_RUNNER_HOME/bin/pax-run.sh etc/counter-demo.pax --args=file:etc/runner.args
2010-09-09 17:14:23,435 INFO - Terracotta 3.3.0, as of 20100716-150712 (Revision 15922 by cruise@su10mo5 from 3.3)
2010-09-09 17:14:24,794 INFO - Successfully loaded base configuration from file at...
2010-09-09 17:14:30,101 INFO - Connection successfully established to server at ...
__________                 __________
\______   \_____  ___  ___ \______   \__ __  ____   ____   ___________
 |     ___/\__  \ \  \/  /  |       _/  |  \/    \ /    \_/ __ \_  __ \
 |    |     / __ \_>    <   |    |   \  |  /   |  \   |  \  ___/|  | \/
 |____|    (____  /__/\_ \  |____|_  /____/|___|  /___|  /\___  >__|
                \/      \/         \/           \/     \/     \/       
 
Pax Runner (1.4.0) from OPS4J - http://www.ops4j.org
 
----------------------------------------------------
...

Review the first lines showing that the Terracotta client successfully estalished it’s connection to the server. If those lines are missing please double check the path to your “boot JAR”.

We added some OSGi commands to interact with our clustered POJO counter:

osgi> help
...
---Sovereign counter commands---
	inc - increment the global counter
	currentValue - show current counter value

osgi> inc
4
 
osgi> currentValue
4

Start another application and have fun with the clustered counter….

Sources:

[1] Terracotta Integration Modules Manual
[2] Concept and Architecture Guide
[3] Java SE Documentation – Java – the Java application launcher

Tags: equinox, terracotta