Saturday, November 24, 2012

Recently we were doing some load testing against Carbon servers. Soon we realized that there was no easy way to get average memory usage and CPU utilization. (apart from taking jconsole screenshots). End of the day we automated the whole testing process. Below is the JMX client [1] that we used to get details out from the remote running Carbon Server.

It dumps the details to a CSV file. Later you can process the CSV s in batch mode.

Sunday, September 16, 2012

As I have explained in one of my previous posts, WSO2 Carbon has undergone some major architectural changes from its 3.x.x version to version 4. One of our main goals during those changes was to make Carbon running in a pure-OSGi container instead of running it in a bridged mode. At some point we were considering to drop off the web-app mode deployment, altogether from the C4 release on-wards. However, thanks to sound architectural decisions that we have made in the past, we realized that it is possible to support web-app mode deployment of WSO2 Carbon without major hassles.

Why Web-app mode deployment?

More often than not, large organizations have their middle-ware platform/part of it, in place. Not only they have application-servers/ESBs/etc ,but also they may already have built monitoring mechanisms/billing systems based on the existing echo system (Normally internal policies/politics within the organization plays a major role too ;) ). If somebody wants to make use of a WSO2 product within such restrictive environments, the web-app mode deployment of WSO2 Carbon comes to the rescue.

Having said that we strongly recommend running WSO2 Carbon servers in standalone mode.

Pre-requisites

Download Apache Tomcat 7.0
Download WSO2 Carbon 4.x.x

Steps to deployCreating the war fileExtract the product zip directory to the local file-system. From here onwards I'm referring the root of the extracted product directory as $CARBON_HOME.

Under the directory $CARBON_HOME/webapp-mode there is a directory called WEB-INF. As the name suggests, this is the Carbon bare bones web-app. Move it in to a directory with a preferred name. and put the whole directory structure in to the 'webapps' directory of Apache-Tomcat. My preferred directory name is 'crbn' - please note that, the name of this directory will get picked as the context root of our web-app by Tomcat.

Create a directory named "carbon_repo" in a preferred location. For me its located in '/home/pradeep/carbon_repo'. Copy the 'repository' directory found under $CARBON_HOME to the newly created 'carbon_repo' directory.

From here on-wards of this blog post, I'm referring the directory location of 'carbon_repo' as $CARBON_REPO

Now the directory structure would look like,

carbon_repo/

└── repository

├── components

├── conf

├── data

├── database

├── deployment

├── logs

├── README.txt

├── resources

└── tenants

Replace the DB file location found in '$CARBON_REPO/repository/conf/datasources/master-datasources.xml' with the new path.

The new master-datasource.xml DB location entry looks like,

Remove all the tomcat related jars from the '$CARBON_REPO/repository/components/plugins' directory. The jars represent the embedded version of tomcat. Since our intention is to run carbon under provided servlet container, we no longer need theses jars. The list of jars include,

org.wso2.carbon.tomcat_4.x.x.jar

org.wso2.carbon.tomcat.ext_4.x.x.jar

org.wso2.carbon.tomcat.fragment.dummy_4.x.x.jar

org.wso2.carbon.tomcat.patch_4.x.x.jar

tomcat_7.0.28.wso2v1.jar

copy the jars found under $CARBON_HOME/webapp-mode/bundles to '$CARBON_REPO/repository/components/plugins' directory. namely,

org.wso2.carbon.http.bridge-4.x.x.jar

org.wso2.carbon.servletbridge-4.x.x.jar

and add the following two entries to the 'bundles.info' located under '$CARBON_REPO/repository/components/configuration/org.eclipse.equinox.simpleconfigurator' directory.

Configure webContextRoot and backendServerURL in carbon.xml
Update the fields to,

respectively in the '$CARBON_REPO/repository/conf/carbon.xml'Endorsing JVM provided classes
Like any other complex java program, Carbon makes use of endorsed libraries for XML parsing/APIs/etc. To endorse libs,
create a directory named 'endorsed' in $TOMCAT_HOME . Move all the jar files found under $CARBON_HOME/lib/endorsed to newly created $TOMCAT_HOME/endorsed directory.Starting the server and accessing the management console

set the CARBON_HOME system property to the created 'carbon_repo' directory,

export CARBON_HOME=/home/pradeep/carbon_repo

start Tomcat server, using,

./bin/catalina.sh run

access the carbon management console using,

https://10.100.2.1:8443/crbn/carbon

Please Note
WSO2 Carbon is a fully fledged server runtime. This blog post is for get it working with Apache Tomcat servlet container. The steps depend on the application server.

Saturday, August 11, 2012

With the 4.0 release of WSO2 Carbon we have changed the internal architecture of the platform in a significant way. In the pre Carbon 4 era, WSO2 carbon used to get deployed as a web-app on apache-tomcat servlet container under the hood. The hight level architecture looked like,

As shown in the above diagram Carbon framework get deployed as just another web-app in Apache tomcat server. Hence, in the in the Carbon 3.2.0 architecture there were two Carbon environments,

The OSGi environment - the area where coloured in light blue

The Non OSGi environment - rest of the area

The requests were routed to the OSGi environment using the bridge-servlet mechanism.(read the equinox getting started guides for more details)

However with this approach there was a noticeable disadvantage:

JAR duplication - Carbon based products like WSO2 Applicaton Server allows users to deploy web-applications. To share some of the core APIs with the third-party web-apps we had to move them-out/duplicate from the Carbon OSGi environment. (Eg: Carbon Context API).

The Solution : Make Tomcat a bundle and move it in to the OSGi environment

In the new architecture we run our application within a pure OSGi environment. There is no bridging between environments. One of the reasons that blocked us from moving to this clear architectural model was the unavailability of tomcat as a bundle. We created a OSGi bundle version of embedded tomcat, which is somewhat similar to existing OSGified jetty servlet container.

Some of the pros of the above approach includes:

1. There is no jar duplication. Hence almost all the carbon related jars resides in $CARBON_HOME/repository/components/plugins directory
2.Now the all the Carbon libs are visible to the third-party web-apps. This is one of reasons why we are going to support native support for CXF web-apps.
3. Now carbon can be deployed in any OSGi framework/platform with minimal set of modifications - its a set of bundles.

However a techy user still can deploy Carbon as a web-app in another servlet container like Apache-tomcat standalone server, JBoss, IBM WAS, etc. :)
The documentation will follow.

Subscribe Now

Search This Blog

About Me

Engineer at WSO2 Inc. Completed B.sc in Engineering with first-class honours at the University of Moratuwa, Sri Lanka.
My area of interests includes Systems programming,Artificial intelligence & studying about mechanical properties of vehicles/weapons.