| res ipsa loquitur

~ Latest Posts ~

This post describes how to check whether the current node is the leader node of an ESB cluster. An example use-case of using this property is to write a cluster aware scheduled task in WSO2 ESB.

While writing a proxy service or a sequence, there might be an instance where you want only one ESB node to do a particular task. In that case, we can use the leader node in the cluster or try to get hold of a cluster-wide lock (using a DB based solution or Hazelcast). This blog post explains how to achieve this using Hazelcast leader node.

Hazelcast Leader node

WSO2 carbon server which WSO2 ESB is built upon uses Hazelcast as the cluster coordination implementation. In Hazelcast, there is a mechanism to reliably get the leader node of a cluster. Only one node in a cluster at a given time becomes the leader node. We can use this property of Hazelcast within WSO2 ESB using either a script mediator or a class mediator to get the leader node.

Retrieving leader with a Class mediator

Following is a Java code snippet to get the leader node of a Hazelcast cluster. We can use this within a class mediator to get the leader node of the ESB cluster.

You can follow this guide to write your own class mediator.

Retrieving leader with a Script Mediator

We can use the same Java code with some modifications within the script mediator as well. This option is much easier to implement and deploy in an ESB cluster.

Use case

One of the use cases of this property is to create a cluster aware scheduled task in WSO2 ESB.

Up to ESB 4.8.1 scheduled tasks cannot be controlled to be scheduled only in a single node at a time. The only option is to use pinned servers, but this has a single point of failure.

Even though the scheduled tasks deployed in the cluster injects a message to each proxy or sequence in the cluster, we can make only one proxy service to mediate the message by evaluating the leader node property as mentioned above.

Hope this is useful to someone.


Written by Asitha Nanayakkara

With ESB 4.9.0 release we can achieve this directly using the property mediators registry scope.

In WSO2 ESB 4.8.1 there is no direct way to save content to registry through stock synapse mediators. This post describes two possible options we have with ESB 4.8.1 to save content to the registry. Those are by using either the Script Mediator or the Class Mediator.

Following examples shows how to store the value of property myProperty of type String in message context into the registry path conf:/store/myStore

##Script Mediator

Achieving this with script mediator is relatively easy. Note that using the script mediator will have some performance impact on your mediation logic.

Here is a sample code snippet of a script mediator to save the value stored under myProperty in message context to the registry.

##Class Mediator

First of all, you need to create a class mediator. You can follow this guide to write your own class mediator. After that what you need is to write some Java code similar to following to store the content into the registry.

##Retrieve content

To retrieve the stored content you can simply use the get-property XPath function with registry scope as follows.

<property name="regContent"
          expression="get-property('registry', 'conf:/store/myStore')"/>


Written by Asitha Nanayakkara

There are lot of architectural changes in WSO2 Message Broker (MB) 3.0.0. We can fairly say its totally different in terms of the architecture compared to WSO2 MB 2.2.0. All these changes were done to improve performance and give more flexibility to the end user.

One of the key features that’s introduced with MB 3.0.0 is its RDBMS support. Previously it was all about Cassandra. Whether you like it or not If you are using MB you had to stick with Cassandra. With MB 3.0.0 you can connect MB to either Cassandra (Either with Hector or CQL), MySQL, MS-SQL, Oracle, PostgresSQL or H2 data store.

##Design In MB, core functionality is handled by Andes. Andes is protocol independent and is cluster aware. MQTT and AMQP protocol implementations talks to Andes to get its work done. Andes mainly uses two data stores for data persistence. They are AndesContextStore and MessageStore.


  • MessageStore is an interface in MB. All messages related persistence tasks (message storing/retrival/deletion) are handled by classes implementing this interface.
  • AndesContextStore is an interface in MB. Tasks that are not directly related to messages (create/retrieve/delete queues, exchanges etc) but need to be persisted are handled by classes implementing this interface.

By way of AndesContextStore and MessageStore interfaces, in MB 3.0.0, tight coupling between specific Database Management System (DBMS) and Andes is removed. Therefore supporting a new DBMS is a matter of implementing a class with specific DBMS related implementation and configuring MB to use that implementation at start-up.

Following is the class diagram of MB 3.0.0 that comes with specific implementation for several DBMS types

UML class diagram of DBMS design

RDBMS related implementations are written using ANSI SQL so that it can be used with many RDBMS’s. This includes MS-SQL, Oracle, MySQL, PostgresSQL, H2.

##Extension points With this new design there is an option to write custom RDBMS or any DBMS specific store and plug it to MB. For instance you can write custom classes implementing AndesContextStore and MessageStore interfaces to harness performance gaines by using specific SQL statements supported by a given database.

Written by Asitha Nanayakkara

##Problem There might be an instances where you want to connect to a WSO2 server (eg: WSO2 Identity Server) using an Axis2 client stub with an SSL connection. In that case you need to set a trust store for the client application to trust the server. Trusting the server or not is totally up to the client. And the default trust store of Java doesn’t have the self signed certificate of a default WSO2 server. Hence we usually use system properties to set the correct trust store.

There might be a requirement to totally ignore the certificate and trust whatever the server it connects to by ignoring the trust store. Most probably in a testing environment. Way to do this is some what different from a usual Java HTTP client when we use Axis2 client stub implementations.

##Solution In Axis2 there is a class for this specific purpose, to trust all the servers it connects to, TrustAllTrustManager. We can use that TrustManager to create an SSLContext which trust all the servers.

 SSLContext sslCtx = SSLContext.getInstance("http");
 sslCtx.init(null, new TrustManager[] {new TrustAllTrustManager()}, null);

Next we set SSLContext to axis2 stub implementation as follows.

	new Protocol("https", new SSLProtocolSocketFactory(sslCtx), 443)

After that we can use this stub to communicate with the server without any failing SSL handshake issue.

##Gotchas Most common mistake we do when trying to ignore the trust store using Axis2 stubs is that we use something similar to following.

// SSLContext sslContext; created to trust all servers

// Then we set the context to HTTPSURLConnection

// Create all-trusting host name verifier
HostnameVerifier validateAllHosts = new HostnameVerifier() {

	public boolean verify(String hostname, SSLSession session) {
		return true;

// Set the all-trusting host verifier

Problem is underlying Axis2 client doesn’t use the HTTPSURLConnection hence this code has no effect to the underlying Axis2 client.

Extension points

There might be an instance where we need to add a given set of certificates to be trusted by our client application. We can use System properties to for that. Instead this can be also achieved by adding our own implementation of TrustManager as follows.

// Create the custom trust manager
TrustManager[] customTrustManager = new TrustManager[]{ new X509TrustManager() {

	public java.security.cert.X509Certificate[] getAcceptedIssuers() {
		X509Certificate[] trustedCerts;
		// Set trusted certificates. Or you might return an already
		// created array of trusted certificates
		return trustedCerts;

	public void checkClientTrusted(X509Certificate[] certs, String authType) {

	public void checkServerTrusted(X509Certificate[] certs, String authType) {

// Create the SSL context and set the custom trust manager  
sslContext = SSLContext.getInstance("SSL");
sslContext.init(null, customTrustManager, new java.security.SecureRandom());

// Set the SSLContext to the stub as mention above

That’s all for this gotcha!

Written by Asitha Nanayakkara

This is my go at explaining subtle coding issues that I face in everyday programming and how to properly overcome them. Idea is to make you aware of the pitfalls in coding so that you’ll be able to understand and do a better job when you come across similar puzzling moments.

##Problem I’ll start my series of gotchas with a Java long type related gotcha. Here is the Java code segment.

long referenceStart = 41 * 365 * 24 * 60 * 60 * 1000; //this is 2011
System.out.println("value: " + val);

What would be the output of this code segment? Yes this is a huge value. If we calculate, we get the following answer.

Expected output: value: 1292976000000

Unfortunately what we get as the output is the following

Actual output: value 190843904

##Puzzled ??? First thing that comes to our mind is numeric overflow. Is this value 1,292,976,000,000 too big for a long to handle? If we look at the maximum value of a long, it is 9,223,372,036,854,775,807 that is 263 -1.

The expected value is less than the maximum value a long can hold. Therefore this can’t be a numeric overflow. Then why is this giving an incorrect answer?

##Gotcha! If we look at the calculation of referenceStart closely, we can see that JVM needs to do five multiplications before it assigns the final value to referenceStart, which is a long. But since the multipliers and multiplicands are integers JVM will do an integer multiplication, even though we assign it to a long. Maximum value of int type is 2,147,483,647 that is 231-1, which is lot less than our expected answer. This causes a numeric overflow. the value is converted to a long only when it assigns the value to referenceStart. That’s why we get this incorrect answer.


Solution is to make JVM do a long multiplication instead of integer multiplication. How do we do that? Easy, we add an L after each value.

// Make the calculation long to avoid numeric overflow
long referenceStart = 41L * 365L * 24L * 60L * 60L * 1000L;
System.out.println("value: " + val);


I came across this while I was meddling with some old code. It was lying around for some time going through some release cycles as well. Luckily this didn’t lead to any unpleasant scenarios. All along the IDE was complaining about a numeric overflow. Finally this led us to take another look at the code.

Takeaways from this is always be vigilant about the type of multiplication the JVM might do and be aware of IDE/compiler warnings.

Written by Asitha Nanayakkara