Wednesday, October 31, 2012

[WSO2] Deployment Synchronizer for Artifact Synchronization Between the WSO2 Cluster Nodes - Webinar slides

I and Pradeep did a webinar on Deployment Synchronizer feature of WSO2 products with focus on practical aspects with a demonstration on setting up a minimal wso2 cluster setup w/ Deployment Synchronizer enabled. This covers most of the details that are needed to know on this subject. I did the Demonstration while Pradeep Fernando covered the technical aspects.

You can view the slides from below.

You can see the details on this webinar at -

The abstract goes as -

Setting up a cluster is important when developing enterprise software and deploying them in production environments. Distributing deployment artifacts & related metadata to all nodes in a homogeneous cluster is a typical requirement for a clustered deployment of any middleware platform. In such a cluster, all nodes should contain the deployed artifacts as well as the related metadata.

The Deployment Synchronizer (DepSync) is the mechanism used in the WSO2 platform for distributing these artifacts and metadata across all nodes in the cluster. It provides the ability to synchronize data between the worker nodes of a product cluster. When used with the WSO2 Application Server, or the WSO2 ESB, you can synchronize your deployable artifacts like web services, and web applications etc. across the cluster nodes. In addition, with the latest WSO2 Carbon 4 release, WSO2 provides the ability to synchronize service metadata which includes service policies, transports, and service-type specific data. Now you only have to deploy and configure services in one node - called the manager. Then, DepSync will replicate those to other nodes - workers.

In this webinar, we will present how this is done in the WSO2 Cloud-enabled middleware platform. Typical deployment artifacts will include webapps, JAXWS/JAXRS apps, data services, proxy services, and BPEL processes . The WSO2 platform also natively supports multi-tenancy. Tenants & tenant artifacts are loaded on demand. We will demonstrate how DepSync works efficiently with multi-tenancy.

Make sure to join Kasun Gajasinghe and Pradeep Fernando as they introduce DepSync which reduces the complexity of configuration management of a clustered deployment, and provides a consistent way to synchronize the cluster with zero downtime.

Monday, October 8, 2012

Clear QPid/Andes/Cassandra JMS Queues

This tutorial shows how to clear the JMS queues of Cassandra. It should be noted that this method clear all the queues; you can't clear queue of your selection. This is useful where you have sent a message, and while it's in the queue something went wrong. There could be errors in processing the message due to incorrect settings etc. Since the queues are accessed FIFO (First-In-First-Out), if a message is hanged in the queue, it'll also block all other messages in the queue because they waits until the first message is processed.

At WSO2, we use WSO2 Message Broker to connect with Cassandra via WSO2 Andes (extended version of QPid) while WSO2 ESB will utilize these to maximum use. Message Store and Message Processor mediators that comes with WSO2 ESB uses JMS queues extensively.

  • Shutdown all the servers if they are running
  • Open up Cassandra-HOME/conf/cassandra.yaml
  • Remember the log locations you have set. Typically, you would have set 
    • data_file_directories
    • commitlog_directory
    • saved_caches_directory
  • Delete all three files folders. (By default, these locations point to relevant child folder in Cassandra-HOME/logs/cassandra/)
It's all set. Now, start the cassandra and other servers. The queues will be cleaned. Actually, what  happens during this process is that it removes all the queues. When the servers start, they re-create the missing queues. That should be it! :)

Thursday, October 4, 2012

Carbon 4.0.0 - JMS Address endpoint URL format

This applies when you are using WSO2 ESB 4.5.0+ and WSO2 MB 2.0+. In WSO2 Message Broker 2.0, we use Andes as the message broker, an extended version of QPid.

The format to use when defining a JMS endpoint is like follows. Remember The configuration will be different if you are not using Andes.


If you are want to create an address endpoint with JMS in WSO2 ESB 4.5.0, then it will look following.

 <endpoint name="MaterialMasterProxyEndpoint">
     <address uri="jms:/MaterialMasterProxy1?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&amp;java.naming.factory.initial=org.wso2.andes.jndi.PropertiesFileInitialContextFactory&amp;java.naming.provider.url=repository/conf/;transport.jms.DestinationType=queue"/>

In ESB 3.0.1, we defined the address endpoints as follows.


Tuesday, October 2, 2012

[Linux] Copy files faster cp command

Every Linux user is familiar with file copy command, cp (copy). As an user who uses this frequently in a day, I can't help but wonder about possible alternatives to cp. CP is terrible when copying large number of files that are small in size. So, after digging in the internet, I found the following command to be a little more faster than cp command when it comes to copying smaller files.

tar cf - dir1 | (cd dir2; tar xf -)

With this, you can move an entire directory from dir1 to dir2. Here's an example.

tar cf - images/ | (cd /media/gentoo_/images/ tar xf -)