Exploring the History of the Silicon Chip

A few weeks back I visited the Intel Musuem along with my colleagues Sumedha and Nuwan. The museum is located at Intel’s headquarters in Santa Clara, California- the heart of Silicon Valley. It showcases Intel’s products and processes while giving a deep insight to the history of microprocessors. They exhibit almost all their land mark processor designs from the past, equipment and materials used to manufacture silicon chips and some of Intel’s innovative creations such as ‘Arti’ the talking robot.

Here are some of my favorite pictures from the trip....

Apache Xerces2/J 2.11.0 Released

The Apache Xerces project team is pleased to announce that version 2.11.0 of Apache Xerces-J is now available.

Xerces-J 2.11.0 can be downloaded at: http://xerces.apache.org/mirrors.cgi

This release expands on Xerces' experimental support for XML Schema 1.1 (see Xerces-J-bin.2.11.0-xml-schema-1.1-beta.zip) by providing implementations for the simplified complex type restriction rules (also known as subsumption), xs:override and a few other XML Schema 1.1 features. Xerces-J 2.11.0 also introduces experimental support for XML Schema Component Designators (SCD). It fixes several bugs which were present in Xerces-J 2.10.0 and also includes a few other minor enhancements.

Specifically, the changes introduced in this release are:

• Implemented XML Schema 1.1's simplified complex type restriction rules (also known as subsumption)
• Added support for XML Schema 1.1's overriding component definitions (<xs:override>)
• Added experimental support for a parser and evaluator for XML Schema Component Designators (SCD)
• Implemented support for the vc:typeAvailable, vc:typeUnavailable, vc:facetAvailable and vc:facetUnavailable attributes for conditional inclusion processing in XML Schema 1.1 documents
• Implemented support for allowing xs:group as a child of xs:all in XML Schema 1.1 documents
• Made several enhancements to the support for assertions in the XML Schema 1.1 implementation
• Improved the ways in which the XML Schema API exposes values and identity constraint information
• Fixed a bug where XMLSchemaValidator.findSchemaGrammar() was not getting called for substitution groups
• Fixed a bug in the regular expression support which was introduced in the previous release. See JIRA Issue XERCESJ-1456 for details
• Fixed multiple issues with decimal precision in the processing of xs:precisionDecimal value
• Fixed various bugs and made various improvements

A complete list of JIRA issues resolved in this release is available here: http://s.apache.org/pI

For more information please visit: http://xerces.apache.org/xerces2-j/

SOA Meets the Cloud

We just released WSO2 Stratos v1.0.0, the SOA PaaS solution based on WSO2 Carbon. Stratos enables you to run WSO2 middleware on a cloud infrastructure in a completely multi tenanted environment. This release brings you following SOA middleware services:

• WSO2 Enterprise Service Bus as a Service
• WSO2 Application Server as a Service
• WSO2 Data as a Service
• WSO2 Governance as a Service
• WSO2 Identity as a Service
• WSO2 Business Activity Monitoring as a Service
• WSO2 Business Processes as a Service
• WSO2 Business Rules as a Service
• WSO2 Mashups as a Service
• WSO2 Gadgets as a Service

With Stratos you can deploy webapps, web services, mediation flows, gadgets and business processes on the cloud. Just like all WSO2 products, Stratos is also free and open source. Try out Stratos for free at cloud.wso2.com.

ASF Says "It's On"

As most of you know there's an ensuing battle between the Apache Software Foundation (ASF) and Oracle over Java and Apache Harmony. The roots of this conflict go all the way back to the time when Java was mainly driven by Sun Microsystems. However with ASF getting re-elected as a ratified JCP executive committee member, things are starting to take an interesting turn. A couple of days back ASF made a bold statement indicating that they are going to vote down the upcoming Java SE 7, which Oracle is pushing forward so hard. ASF is also urging other JCP members to back ASF on this. ASF has indicated that they are not afraid to terminate their ties with JCP if needed. This is pretty huge for a group that maintains an overwhelming number of world class Java projects including Tomcat, Maven, Geronimo, Ant and Derby. (I also happen to be a committer for a couple of Java projects at ASF)

There are currently so many news articles on the web covering this conflict end-to-end. I found the news report from The Register to be quite interesting and amusing at the same time. Here's a little excerpt:

Oracle was forced to eat crow and congratulate ASF for its near unanimous election back onto the JCP's SE and EE executive committee. It was an election that saw its own nominee - the little-known-outside-Oracle-circles Hologic - soundly rejected by JCP members.

Congratulating ASF, Oracle's spokesperson on Java SE, Henrik Ståhl, claimed Oracle still respected ASF and wanted to work with the group. "Our disagreement around TCK licensing does in no way lower our respect for and desire to continue to work with Apache," Ståhl said here.

On Tuesday, the ASF told Ståhl and Oracle just exactly where they could shove their "respect" with a statement saying it is walking out of the JCP unless Harmony gets a license.

Another interesting news report is available on IT World.

Taming the Java Garbage Collector

Tuning the garbage collection in JVM is one of those things that developers often tend to ignore and overlook. But if done properly, it can save you hundreds of megabytes worth precious memory, without making a significant impact on the application performance. Also GC tuning becomes an absolute necessity in certain applications due to various QoS requirements such as real-time processing, low response time and high throughput. So today I'm going to discuss a little bit about GC in JVM and how to properly tune up GC for best application performance. My discussion is entirely focused on Java 5 and 6, so if you are using an older JVM you are at the wrong place.

Before we jump into the discussion on GC tuning we need to have a basic understanding on the various concepts associated with GC. So here goes...

What is garbage collection?

Garbage collection is the process of finding objects which are no longer reachable from references in the executing code, and reclaiming the memory occupied by such objects. An object which is reachable by at least one reference in the executing code is considered to be 'live'. Objects which cannot be reached by any references are called 'dead' objects. So the process of garbage collection can be also defined as the process of finding dead objects in the memory and reclaiming the memory used by them. In general, a garbage collector is responsible for 3 tasks:

1. Allocating memory for new objects
2. Ensuring that any referenced objects (live objects) remain in memory
3. Recovering memory used by objects that are no longer reachable (dead objects)

The following characteristics govern the notion of a 'good' garbage collector:

• Safe (never reclaims a live object)
• Comprehensive (a dead object does not remain unclaimed for more than a small number of collection cycles)
• Efficient (does not introduce too long pauses)
• Defragmentation (does not leave the memory fragments all over the place)
• Scalable (allocation and deallocation scales well in multithreaded systems)

It is not possible and necessary for a garbage collector to display all these desirable characteristics at once. Usually each garbage collector has its own strengths and weaknesses.

GC Classification

Garbage collectors can be classified based on a number of factors.

Serial vs Parallel:

In serial collection only one collection occurs at a time (even with multiple CPU cores). In parallel collection, the task of collection is divided into subtasks and executed in parallel, possibly on multiple CPUs. This speeds up collection but is more complex and leads to potential fragmentation.

Stop-the-world vs Concurrent:

Stop-the-world collectors suspend the entire application during collections. Concurrent collectors run concurrently with the application (there could be occasional stop-the-world collections). With concurrent collection, freeze times are shorter but it has to operate on the objects which are being used by the running application. This adds more overhead on the collector and requires more CPU power and heap.

Compacting vs Non-compacting vs Copying:

Compacting collectors arrange all the live objects together in contiguous memory blocks. Then the remaining space can be considered free. This way the collection is slow but the allocations are faster. Non-compacting collectors free dead objects in-place. This leads to faster collections but also a recipe for fragmentation. Copying collectors copy (in contrast to moving) all the live objects to a different area in the memory. Then the source area can be considered free. This leads to slower and expensive collections but provides better allocation performance.

Generational Collection

Modern garbage collectors follow a scheme known as 'generational collection'. With this approach, the heap memory is allocated to two or more regions known as generations. A generation is a block of memory which contains objects of a certain age. In many implementations there are two generations, one for young (new and reasonably new) objects and one for old objects. Young generation is usually much smaller compared to the old generation. Generational collection allows employing different GC algorithms in different generations. This enables selecting a suitable algorithm based on the maturity of the objects.

Generational collection makes use of an interesting characteristic of applications, often referred to as the "generational hypothesis". This hypothesis states:

• Most allocated objects are not referenced for long (they die young - sometimes also stated as infant mortality)
• Few references from older objects to younger objects exist

Based on this hypothesis, modern garbage collectors run collections on the young generation frequently. This is fast and efficient because the young generation is small and likely to contain many dead objects. Objects that survive some number of young generation collections are moved (tenured) to the old generation. Because old generation is much larger, its occupancy grows very slowly. Therefore old generation collections are infrequent. But when they do occur, they tend to take a much longer time to complete.

In new HotSpot JVMs, the garbage collector divides the heap into 3 generations:

• Young generation - contains newly allocated objects
• Old generation - objects that has survived some number of young gen collections and some very large objects that were directly allocated in old gen
• Permanent generation (perm gen) - contains classes, methods and associated descriptors which are managed by the JVM

The young generation is further divided into 3 regions. The larger division is known as the Eden. This is where almost all the new object allocations take place (under special circumstances, large objects may get allocated in the old generation). The other smaller spaces are known as survivor spaces. One of the survivor spaces are always kept empty until the next young generation collection.

When an old generation fills up a full collection (major collection) is performed. All generations are collected during a full collection. First the young generation is collected using the young generation collection algorithm. Then the old generation collection algorithm is run on the old generation and permanent generation. If compaction occurs, each generation is compacted separately. During a full collection if the old generation is too full to accept tenured objects from the young generation, the old generation collection algorithm is run on the entire heap (except with CMS collector).

Available Garbage Collectors

HotSpot JVM contains 3 garbage collectors:

1. Serial collector
2. Parallel collector
3. Concurrent mark-sweep collector

In addition to that there is a special enhanced version of the parallel collector known as the parallel compacting collector. Let's see how each of these collectors work.

Serial Collector (Mark-Sweep-Compact collector)

This is the collector used by default on Java HotSpot client JVM. It is a serial, stop-the-world, copying collector. Because it is serial and operates in the stop-the-world mode it is not a very efficient collector.

Young generation collection:

• Live objects in Eden are copied to the empty survivor space (objects that won't fit are directly copied to the old generation)
• Live objects in the occupied survivor space are copied to the empty survivor space (relatively old objects are copied to old generation)
• If the free survivor space becomes full during the process, remaining live objects in Eden and occupied survivor space are tenured
• At this point Eden and the occupied survivor space contains only dead objects and so can be considered empty - The previously free survivor space contains some live objects
• The two survivor spaces switch roles

Old/Permanent generation collection:

• A two phase Mark-and-sweep algorithm is used to clean up dead objects
• After that a sliding compaction (live objects are slided towards the beginning of the generation) is performed to compact the generations

Parallel Collector (Throughput Collector)

This is very similar to the serial collector in many ways. In fact the only notable difference is that parallel collector uses multiple threads to perform the young generation collection. Other than that it uses the same algorithms as the serial collector. The number of threads used for collection is equal to the number of CPUs available. Because of the parallel collection feature, this collector usually results in much shorter pauses and higher application throughput. However note that the old generation collection is still carried out using a single thread in serial fashion. This is the default collector used in Java HotSpot server JVM.

Parallel Compacting Collector

This is an enhanced version of the parallel collector. It uses multiple threads to perform the old generation collection as well. The old generation collection divides the generations into regions and operate on individual regions in parallel. The algorithm used for old generation collection is also slightly different from what's used in serial and parallel collectors.

Concurrent Mark-Sweep Collector (CMS Collector)

While the parallel collectors give prominence to application throughput, this collector gives prominence to low response time. It uses the same young generation collection algorithm as the parallel collectors. But the old generation collection is performed concurrently with the application instead of going to stop-the-world mode (at least most of the time). A collection cycle starts with a short pause known as the initial mark. This identifies the initial set of live objects directly reachable from the application code. Then during the concurrent marking phase, collector marks all live objects transitively reachable from the initially marked set. Because this happens concurrently with the application not all live objects get marked up. To handle this, the application stops again for a second pause for the remark phase. Remark phase is often run using multiple threads for efficiency. After this marking process a concurrent sweep phase is initiated.

CMS collector is not a compacting collector. Therefore it uses a set of free-lists when it comes to allocation. Therefore the allocation overhead is higher. Also CMS collector is best suited for large heaps. Because collection happens concurrently, the old generation will continue to grow even during collection. So the heap should be large enough to accommodate that growth. Another issue with CMS is floating garbage. That is objects considered as live may become garbage towards the end of the collection cycle. These will not get immediately cleaned up but will definitely get cleaned up during the next collection cycle. CMS collector requires lot of CPU power as well.

Unlike other collectors, CMS collector does not wait till the old generation becomes full to start a collection. Instead it starts collecting early so it can avoid old generation getting filled up to the capacity. If the old generation gets filled up before CMS kicks in, it resorts to the serial stop-the-world collection mode used by serial and parallel collectors. To avoid this CMS uses some statistics regarding previous collection times and the time taken to fill up the old generation. CMS also kicks in if the old generation occupancy exceeds a predefined threshold known as the initiating occupancy fraction. This is a configurable parameter and defaults to 68%.

There is a special mode of operation for the CMS collector known as the incremental mode. In the incremental mode, concurrent collection cycles are broken down into smaller chunks. Therefore during a concurrent collection cycle, the collector will suspend itself to give full CPU to the running application. This in turns reduces the impact of long concurrent collection phases. This mode is particularly useful in cases where the number of CPUs is small.

Selecting the Appropriate Collector

Most of the time JVM is smart enough to select the right collector for the situation by analyzing the system configuration (see the next section). But since the JVM has no knowledge of the application requirements, sometimes the JVM chosen collector will not be good enough. When it comes to manually selecting a collector for an application, there are no hard and fast rules that say a particular collector is suitable for a given scenario. So there are only a set of general guidelines and recommendations. Most of the time they will work, but there could be exceptions. Hope you find them useful:

• Serial collector is the collector of choice for most applications that run on client-style machines and do not have low pause requirements. On modern hardware this collector can handle a wide range of applications with heaps as small as 64MB.
• If the application has a small data set select the serial collector.
• If the application has no low pause requirements and runs on a machine with a single CPU select the serial collector.
• Parallel collector is best for applications that run on machines with multiple CPUs and do not have low pause requirements.
• If application throughput is the main consideration and slightly longer pauses are acceptable select the parallel collector.
• The parallel compacting collector can be used in almost any scenario where the parallel collector seems suitable. In fact the parallel compacting collector is almost always preferred over the parallel collector. However with this collector a single application can hog the CPU for an extended period of time. Therefore it's not very suitable in cases where multiple JVMs reside on a single large machine.
• CMS collector should be the collector of choice whenever there is a requirement for low pauses and low response time. However this collector makes use of lot of CPU resources. Therefore impact on CPU usage must be carefully evaluated. Usually applications that have large sets of long-lived data (a large old generation), which run on machines with multiple CPUs, tend to benefit from this collector. Web servers and most interactive applications often fall into the category of CMS benefactors.
• If it is needed to run an application with low pause requirements on a machine which doesn't have too many CPU resources, consider using the CMS incremental mode.

Note: Command line options needed to enable different collectors are given at the end of the post

Ergonomics

Modern JVMs has the ability to select a suitable garbage collector, heap size and JVM type by looking at the host platform and the OS. In addition to that, a new way of dynamically tuning memory management has been introduced to the parallel collectors. This way, a user can specify the desired behavior and the collector dynamically tunes the sizes of the heap regions in an attempt to achieve the requested behavior. The combination of platform-dependent default selections and dynamic GC tuning is referred to as ergonomics.

The ergonomics default selections are done based on the 'class' of the machine. A machine is considered to be server-class if it has:

• 2 or more processors
• 2 GB or more physical memory

This applies to all platforms except for 32-bit machines running Windows.

If the machine is classified as non server-class, ergonomics will choose the following settings:

• HotSpot client JVM
• serial collector
• initial heap size of 4 MB
• maximum heap size of 64 MB

For server-class machines it is slightly complicated. However in general it is something like:

• HotSpot server JVM
• parallel collector
• initial heap size of 1/64 th of physical memory
• maximum heap size of 1/4 th of physical memory under an upper limit of 1 GB

One can run the HotSpot client JVM on a server-class machine by explicitly enabling the -client command line option. In that case ergonomics will select the serial collector. Also when the collector selected by ergonomics is not the parallel collector the initial heap size and maximum heap size will be 4MB and 64MB respectively.

Sizing the Heap

There are lots of options available when it comes to sizing the heap, its regions and generations. Most of the time we don't have to meddle with these settings, but there could be exceptional situations where we have to tune them up to obtain optimal performance and avoid out of memory errors. The most common settings related to heap size are the initial heap size and maximum heap size which are set by -Xms and -Xmx command line options respectively. If you set a lower value to the initial heap size than the maximum heap size, JVM will try to start with a heap of initial size and then grow the heap as and when required. If you set equal values to both parameters, JVM will start with the specified maximum heap size.

Another important parameter is the NewRatio value which governs the ratio between the old generation size and young generation size. On most server class systems this defaults to 8. That means the old generation is 8 times larger than the young generation. If the application tends to do lot of new allocations then reducing this ratio to a reasonable value may not be a bad idea. Reducing this ratio will generally result in less minor collections. The size of the young generation can be further controlled by the NewSize and MaxNewSize options.

We can get the JVM to dynamically grow or shrink the generations based on how they are utilized by setting the MinHeapFreeRatio and MaxHeapFreeRatio parameters. These parameters try to impose some restrictions on the amount of free heap space in each generation. If the free space percentage in a given generation is about to drop below the MinHeapFreeRatio, JVM will expand the generation to meet the lower limit. Similarly generations will be contracted if the free space percentage crosses the MaxHeapRatio.

Command Line Options

Collector selection

• Serial collector: -XX:+UseSerialGC
• Parallel collector: -XX:+UseParallelGC
• Parallel compacting collector: -XX:+UseParallelOldGC (combine with -XX:+UseParallelGC)
• CMS collector: -XX:+UseConcMarkSweepGC

Parallel collector settings

• Parallel GC thread count: -XX:ParallelGCThreads=n
• Desired maximum pause length: -XX:MaxGCPauseMilis=n
• Throughput (percentage of CPU time spent on application - defaults to 99): -XX:GCTimeRatio=n

CMS collector settings

• Enable incremental mode: -XX:+CMSIncrementalMode
• Parallel GC thread count: -XX:+ParallelGCThreads=n
• Old gen occupancy threshold that triggers collections: -XX:CMSInitiatingOccupancyFraction=n

Heap sizing options

• Initial size: -Xms
• Maximum size: -Xmx
• Initial size of the new generation: -XX:NewSize=n
• Maximum size of the perm gen space: -XX:MaxPermSize=n
• Ratio between old and new generation sizes: -XX:NewRatio=n

Debug options

• Print basic GC info: -XX:+PrintGC
• Print verbose GC info: -XX:+PrintGCDetails
• Print details with time: -XX:+PrintGCTimeStamps

References

• http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
• http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
• http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf

Rediscover SOA with WSO2 Carbon & WS-Discovery

One of the hottest features of new WSO2 Carbon 3.0 based releases is the out-of-the-box WS-Discovery support. WS-Discovery is a standard protocol for discovering services and service endpoints. This enables service clients to search for services based on a given criteria and bind with the discovered services. The WS-Discovery specification defines two modes of operation:

1. Adhoc mode

In the adhoc mode, servers advertise the services they have using a UDP multicast protocol. Similarly client applications can search for available services by sending out probe requests over UDP multicast. Servers listening for such probe requests can then send the service information to the client over a unicast channel.

2. Managed mode

In the managed mode, servers and clients use an intermediary known as the discovery proxy for all service discovery purposes. Servers will register the available services with the discovery proxy by sending notifications over HTTP. Then clients can directly probe the discovery proxy to discover the registered services. This mode of operation does not use UDP multicast for any sort of communication. All interactions take place over regular HTTP channels and if needed, HTTPS can be used to provide transport level security.

Starting from version 3.0, WSO2 Carbon framework has full support for WS-Discovery managed mode. The following products ship the necessary WS-Discovery libraries with them by default:

• WSO2 Web Services Application Server (WSAS)
• WSO2 Enterprise Service Bus (ESB)
• WSO2 Data Services Server (DSS)
• WSO2 Governance Registry (G-Reg)

WSO2 G-Reg has the ability to act as a discovery proxy. This mode is enabled by default and user doesn't have to configure anything in the G-Reg side. In products like WSAS and DSS, WS-Discovery support should be manually enabled by pointing them to an already existing discovery proxy. Once configured, these server applications will automatically register the services they have with the discovery proxy. Service information will be synchronized with the discovery proxy at server start up, shutdown and service level updates. This ensures that the information in the discovery proxy are always up-to-date. WSO2 ESB can query one or more discovery proxy instances to find the necessary services and service endpoints. The ESB UI also enables creating proxy services and mediation endpoints using the discovered endpoints.

There are lot of other cool things you can do in Carbon platform with WS-Discovery. There are several plug-ins and extensions available to download and try out as well. I'm planning to post a series of blogs addressing various aspects of WS-Discovery in the next few months. So stay tuned! In the meantime read this article to learn how Jos Dirksen integrated Mule with WSO2 G-Reg using the WS-Discovery capabilities of Carbon framework.

WSO2 Excels at NBQSA

WSO2 bagged four awards at the 12th National Best Quality Software Awards (NBQSA) held last week. NBQSA is an annual competition organized by the Sri Lankan chapter of the BCS. Every year many corporate firms, government organizations, tertiary education institutes and individuals take part in this event. The competition is pretty intense and the winners are also given the opportunity to take part in international events such as APICTA.

This year WSO2 really made their presence felt at NBQSA by winning the following four awards:

• Bronze award for tools and infrastructure apps category - WSO2 Data Services Server
• Silver award for research and development category - WSO2 Gadget Server
• Gold award for tools and infrastructure apps category - WSO2 Enterprise Service Bus
• Glod award for overall victory - WSO2 Enterprise Service Bus

I feel truly proud to be a part of such a dynamic team as the WSO2. Three cheers to WSO2 and all the folks who worked with WSO2 (in past and present) and made these achievements possible.

WSO2 ESB 3.0.1 Up for Grabs

Last week we released WSO2 ESB 3.0.1. This release contains a number of important bug fixes and we highly recommend everyone using WSO2 ESB 3.0.0 to upgrade to the latest release as soon as possible. Please note that this is only a bug fix release and as such it doesn't contain any new features over 3.0.0. Therefore any configuration can be easily migrated to the 3.0.1 from 3.0.0.

Some of the significant fixes available in this release are:

• Fixes to the hot deployment/hot update implementation
• Fixes to the built-in patch model
• Transport fixes (particularly in the NHTTP and FIX transports)
• An Axis2 security fix

To make a long story short, there are more than one reason to migrate to WSO2 ESB 3.0.1. So download your copy today.

From Quadricycle to the Prius

I went to see the California Automobile Museum a few days back. It's located in Sacramento and displays a wide range of classic cars and a few modern cars. If you are an automobile fanatic, this is the place to be. I don't consider myself to be a total car fanatic, but even I loved the place. It's a great place to learn and experience the history of automobile industry and admire the long journey the human race has come in search of faster and safer ways of transportation.

Here are some highlights from my visit:

Experiencing the Nature at Lake Tahoe

A couple of weeks back I was in Auburn, California. During my stay, I got the opportunity to visit the lake Tahoe. It's only a 2-3 hours drive to the magnificent lake from Auburn. Here are some of the breath taking sceneries around the lake.....

Truly awesome experience!

FIX Your SOA with WSO2 ESB

I believe WSO2 ESB is the ONLY complete enterprise service bus which supports the FIX (Financial Information eXchange) protocol. The FIX transport of WSO2 ESB enables the service bus to communicate with FIX acceptors and initiators. FIX messages received by the service bus can be routed, filtered or transformed using the existing set of mediators. If needed, FIX messages can be transformed and sent to external systems over different protocols such as HTTP and JMS.

I published an article titled "FIX Your SOA with WSO2 ESB" which explains how to setup the FIX transport in WSO2 ESB 3.0 and how to use it to implement a variety of integration scenarios. It gives a good overview on how to develop high performance finance data routing systems using WSO2 ESB. Hope you'll like it!

Axis2 TCP Transport Revamped

I recently did some major improvements to the Axis2 TCP transport. The TCP transport enables Axis2 services and clients to send/receive SOAP messages over TCP, using Java TCP sockets. The old TCP transport was very simple and it must be configured globally in the axis2.xml file. Due to this limitation, a service could not open up its own port to listen to incoming TCP messages. All the TCP requests were captured by a single, globally configured port and WS-Addressing headers were used to dispatch the requests to the appropriate services.

The new transport implementation is fairly advanced with a wide range of configuration options. It can be configured globally in the axis2.xml file, or it can be configured at the service level in the corresponding services.xml files. Only the port number was configurable in the previous TCP transport implementation. The new implementation supports all the parameters described below:

• transport.tcp.port - Port number (mandatory parameter)
• transport.tcp.hostname - The host name to which the server socket should be bound
• transport.tcp.backlog - The length of the message back log for the server socket (defaults to 50)
• transport.tcp.contentType - Content type of requests (defaults to text/xml)

In the new transport, if a request is received by a port configured at the service level, it is pre-dispatched to the corresponding service. If the global port receives a TCP message, WS-Addressing headers will be looked up while dispatching.

These improvements are now available in the Axis2 trunk. So feel free to take it for a ride and give us your feedback. I also have some plans to make some improvements to the Axis2 UDP transport. I intend to add multicast support to the existing UDP transport and with that we will be able to support multicast request – unicast response message exchange pattern in Axis2.

WSO2 ESB Mediation Statistics - Let Numbers Do the Talking

WSO2 ESB comes with a mediation statistics component, which allows users to collect and monitor statistics on proxy services, sequences and endpoints. Data gathered by this component can be viewed through the ESB management console or one can even develop some custom code to pump the data into an external monitoring tool.

I just published an article titled "WSO2 ESB Mediation Statistics: What Can Numbers Tell About Your SOA?" which explains the ins and outs of the mediation statistics component along with how to process the collected statistical information by writing custom code. Enjoy!

New Configuration Model of Synapse

If you are trying out a latest Apache Synapse build off the SVN trunk, you will notice that the Synapse configuration model has gone through some significant changes lately. In the past, Synapse was programmed to load the entire mediation configuration (sequences, endpoints, proxy services, tasks etc) from a single XML file, named synapse.xml. Synapse would parse this XML file at startup and construct an object model known as the SynapseConfiguration which contains the definitions of all active mediation components at runtime. While this approach was simple and clean, it had a number of limitations:

• Configuration management becomes a nightmare as the size of the synapse.xml grows. A typical heavy duty configuration would consist of dozens of proxy services, sequences and endpoints. When all these are packed into a single XML file, it becomes difficult to locate a single configuration item quickly.
• With all configuration artifacts stored in a single flat file, it is almost impossible to develop satisfactory tooling support for configuration development and maintenance.
• A team of developers cannot work on configuring a single Synapse instance at the same time.
• Hot deployment is a feature that Synapse has been lacking for years. Being able to hot deploy a proxy service or a sequence into Synapse without having to restart the service bus is a great convenience at development time. But a configuration model based on a single XML file is not at all capable of handling such requirements.

Considering these drawbacks, I implemented a new configuration model for Synapse, known as the multi XML configuration builder. The new model, which is now the default configuration model in Synapse, loads the configuration from a structured file hierarchy, instead of loading the mediation configuration from a single XML file. With this model in place, each endpoint, sequence and proxy service has to be defined in separate XML files. The directory structure for storing these individual configuration files is as follows:

synapse-config
   |
   +-- registry.xml
   +-- endpoints
   +-- event-sources
   +-- local-entries
   +-- proxy-services
   +-- sequences
   `-- tasks

As you can see there are separate dedicated directories for each type of artifacts. Each of these directories can house zero or more XML configuration files. Each file must have the .xml extension to be recognized by the Synapse configuration builder. If you take a look at the source code you will notice that I have enforced this restriction using a Java FileFilter:

    private static FileFilter filter = new FileFilter() {
       public boolean accept(File pathname) {
           return (pathname.isFile() && pathname.getName().endsWith(".xml"));
       }
   };

   private static void createProxyServices(SynapseConfiguration synapseConfig, String rootDirPath)
           throws XMLStreamException {

       File proxyServicesDir = new File(rootDirPath, PROXY_SERVICES_DIR);
       if (proxyServicesDir.exists()) {
           if (log.isDebugEnabled()) {
               log.debug("Loading proxy services from : " + proxyServicesDir.getPath());
           }
           File[] proxyDefinitions = proxyServicesDir.listFiles(filter);
           for (File file : proxyDefinitions) {
               try {
                   OMElement document = parseFile(file);
                   ProxyService proxy = SynapseXMLConfigurationFactory.defineProxy(
                           synapseConfig, document);
                   proxy.setFileName(file.getName());
                   SynapseArtifactDeploymentStore.getInstance().addArtifact(
                           file.getAbsolutePath(), proxy.getName());
               } catch (FileNotFoundException ignored) {}
           }
       }
   }

The mediation registry is defined in the registry.xml file which should be placed at the top level of the file hierarchy.

So does the multi XML configuration builder solve the problems in the old configuration model? Let’s consider the facts:

• With Synapse configuration broken down into smaller, manageable pieces the whole configuration becomes easier to manage and keep track of. As long as the XML files are named appropriately, it is extremely easy to quickly locate a particular configuration item. We recommend using the artifact names to name the corresponding XML files. For an example the file containing the definition of the FooProxy can be named FooProxy.xml.
• With the multi XML configuration builder, developing powerful and elegant tools for creating pieces of the service bus configuration becomes a trivial task. Also one can use conventional configuration management tools and version controlling systems such as Subversion to store and manage the configuration artifacts.
• A team of developers can now work on configuring Synapse. Each developer in the team can work on his own configuration file or set of files.
• Supporting hot deployment is now feasible. As a matter of fact, Ruwan implemented hot deployment and hot update support for Synapse based on the multi XML configuration builder a few weeks back. This feature is now available in the Synapse trunk and will be available for the next Synapse release.

So there you go. Target achieved. There is one little glitch in this approach though. That is how do we handle backward compatibility with older Synapse versions? For instance how can a Synapse 1.2 user, who has a single synapse.xml file, migrate to a new Synapse version? We have provided a solution for that as well. In the new Synapse configuration file hierarchy you can place a synapse.xml file at the top level (alongside with registry.xml). All the mediation components defined in this synapse.xml will be loaded to the service bus at startup along with any other components defined inside the individual directories. So a Synapse 1.2 user can simply copy the existing synapse.xml file to the synapse-config directory in a new Synapse distribution, and it will be picked up by the service bus. In addition to this convenience feature, we are planning on developing some migration tools that can help users to easily migrate an old Synapse configuration file onto a newer version of Synapse.

As far as Synapse is concerned each configuration builder should be associated with a corresponding configuration serializer implementation. Serializers are used to convert the SynapseConfiguration object model back to the textual/XML form. So for the multi XML configuration builder I developed a matching multi XML configuration serializer which can save a SynapseConfiguration object model to a file hierarchy. Similar to the configuration builder this implementation was also heavily dependent on Java file IO APIs. However, after a while we realized that the serializer is not working as expected on certain platforms; most notably on Windows. After running some debug sessions and doing some on-line reading I realized that the Java file IO operations are not consistent on every platform. As a result sometimes the serializer would encounter trouble creating a new file or moving an existing file on Windows.

At this point, my colleague, Rajika suggested using Apache Commons IO API for file manipulation. Commons IO API provides a nice layer of abstraction on top of the standard Java IO APIs. It handles all file IO operations in a consistent and platform independent manner. So I got rid of almost all the Java file IO code in the multi XML configuration serializer and replaced them with corresponding calls to the Commons IO API. Some sample code fragments are shown below:

    private void cleanUpDirectory()  throws Exception {
       // If the target directory already exists and contains any files simply rename it to
       // create a backup - This method does not delete the target directory
       if (rootDirectory.exists() && rootDirectory.isDirectory() &&
               rootDirectory.listFiles().length > 0) {

           if (log.isDebugEnabled()) {
               log.debug("The directory :" + rootDirectory.getPath() + " already exists. " +
                       "Creating a backup.");
           }

           backupDirectory = new File(rootDirectory.getParentFile(), "__tmp" +
                   new GregorianCalendar().getTimeInMillis());
           FileUtils.moveDirectory(rootDirectory, backupDirectory);
       }

       // Create a new target directory
       FileUtils.forceMkdir(rootDirectory);
   }

   private void writeToFile(OMElement content, File file) throws Exception {
       File tempFile = File.createTempFile("syn_mx_", ".xml");
       OutputStream out = new FileOutputStream(tempFile);
       XMLPrettyPrinter.prettify(content, out);
       out.flush();
       out.close();

       FileUtils.copyFile(tempFile, file);
       FileUtils.deleteQuietly(tempFile);
   }

FileUtils is the entry point for file IO operations in the Commons IO API. It provides you with a range of useful methods for managing and manipulating files.

Note that when writing to a file we first write the whole thing to a temporary file and once completed we copy the temp file to the final location. This was required to handle certain edge cases in the hot update implementation. Without that the hot updater will attempt to pickup and process half baked files (Again mostly on Windows – It seems Windows writes to files in chunks).

All in all, Apache Synapse is now equipped with a powerful new configuration model, a matching configuration serializer and hot deployment capabilities that leverage the new configuration model. Speaking of hot deployment, it is also based on the Axis2 hot deployment framework. Therefore it is configured in the axis2.xml file. We are yet to do a Synapse release with all these new exciting features but if you are itching to try them out feel free to grab a nightly build. Also be aware that WSO2 ESB 3.0, which is based on Synapse, has been released and that release contains all these new improvements.

Attention Open Source Developers...

When you keep contributing to an open source project, the project community will eventually reward you by granting you committer rights. However most open source committers don’t realize that committership is a big responsibility. The moment you become a committer of a project, you become responsible for each and every line of code in the project code base. Every single change you make to the project source code affects other committers in the project and all the people around the world who use that software. Therefore as a committer you should stick to some kind of a policy or a code of conduct which governs how you make changes to the project source code. The following is a list of items that I think should be in such a policy. I’m not implying that I have always followed this policy in the past. Rather, I always try my best to stick by it:

1. Before anything else, if your contribution involves API changes, you MUST take the matter to the project mailing list. You MUST NOT make any API changes without notifying your fellow committers and the user base. Sometimes you might feel that the API change you are about to do is rather small, unimportant and trivial. For an example you might spot a spelling mistake in a method signature and feel the urge to correct it immediately. But still, an API change is an API change. If somebody’s using the misspelled method, your change will break his/her code. Also some developers tend to think that certain interfaces in the code base are “not so important” and nobody is using them, and therefore it is ok to make changes to them. Developers like that don’t really understand open source. The truth is there are no unimportant APIs in open source projects. When you make project source code open, you are basically inviting the rest of the world to use that code, develop on top of the APIs to do whatever they want with it. So even though you don’t know it, there could be hundreds of people out there who use the “unimportant” interface you are about to change.

2. Always crate an entry in the project issue tracker to keep track of your contributions. Almost every open source community maintains an issue tracker. At Apache and at WSO2 we mainly use Atlassian JIRA. Whenever you are about to make a change to the source code, consider creating a new entry in the issue tracker before you check-in the patch. In my opinion there are only two excuses for not creating an entry in the issue tracker:

• Adding some descriptive comments to the code (note that comments and Javadocs are two different things)
• Refactoring some private attributes or private methods of a class (eg: renaming a local variable)

Once you have created the entry in the issue tracker, make sure you get it assigned to yourself. Once the relevant changes are checked-in to the code base, mark the entry as resolved. It doesn’t look very professional when you have dozens of open tickets which are not assigned to anyone. It is also not nice to have tickets in the work-in-progress mode, even after it has been fixed on the source code.

3. While making changes to the source code, always follow the coding conventions accepted by your project community. If you come across any badly written or poorly formatted code fix them then and there. Refactor as you go. However do not make any functional changes, which are not relevant to the problem you are attempting to solve. If you come across old functional issues while fixing some other issue, report them on the issue tracker and leave them to be fixed in a future iteration. Generally it’s not a very good idea to solve multiple problems by one commit. That can make things harder to keep track of.

4. When you are actually committing a patch to the code base, make it a point to properly log the changes you are about to check-in. I often commit code into the Apache Subversion repository and WSO2 Subversion repository. Whenever I make a contribution, I always add a couple of lines to the SVN commit log, describing my changes. If it is like a rather large patch, I would mention a summary of the changes in bulleted point form. Also in your commit log message, you MUST mention the ID of the corresponding issue tracker entry. This can really help you track down changes in the future. At Apache and at WSO2 we have integrated JIRA with the Subversion repository. Whenever someone checks a bit of code into the SVN, with a JIRA ID in the commit log message, the relevant JIRA entry gets updated with the information related to the commit (see example). This makes it really easy to identify all the changes done in the source code to resolve a particular issue.

So there you have it! In my opinion, every open source developer should adhere to these key guidelines, whenever making a change to the project source code.

Having said that, an open source committer should never feel uneasy, to make changes to the project source (unless it is specifically restricted by the community - as in the case of a release). If you have done some changes to the code, and if you are confident that the changes you have made are accurate and necessary, you should feel free to check them into the code base. Same applies for patches contributed by the non-committers as well. If a patch solves the problem at hand to a satisfactory level without violating the boundaries of the current design, committers should take necessary steps to check it in. The solution doesn’t have to be “perfect”. At Apache we follow a commit-then-review (CTR) policy, most of the time. This model enables developers to get code changes into the project as early as possible, without worrying too much about the impact they may have on the project. Once the changes have been checked-in, they can be reviewed and fine-tuned as necessary.

However, during my career I have come across developers who at times leave issues open for weeks just because the available patches are not ‘perfect’. While the patches provide a satisfactory solution to the problem at hand, these developers always manage to find some small, irrelevant limitation in the patch, which can be easily fixed in a future iteration. They make it an excuse to not commit the patch. These developers, unfortunately, haven’t grasped the true spirit of open source. They don’t realize that the whole point of open source is to attract as much contributions as possible and correct any problems they might have, as we go on.

Before I wrap up, I’d like to reemphasize that open source committership gives you great power and authority over your project. We all know what comes with great power. Yes, it’s “great responsibility”. So use your powers with care and caution!

A Different Experience...

Last week, I got the opportunity to visit yet another interesting part of the world – the Middle East. I have been to the Dubai airport before, while on my way to United States. But transits don’t count, right? So last week I visited the city of Amman, the capital of the Hashemite kingdom of Jordan. I was there for a whole week. It was not the trip I expected, but in a really good way.

Let’s start with the weather. I was expecting the weather to be burning hot with tons of scorching sunlight. It turns out the weather over there is actually better and far more comfortable compared to the usual weather in Colombo. The temperature is almost as same as in Colombo (around 30 degrees Celsius) but the humidity is nearly 0. So it’s actually very comfy. And during the nights the temperature would drop to something around 18 degrees Celsius resulting in some very cold nights and mornings. I also learnt that they have the usual four seasons over there at Jordan. They even get some snow showers during the winter. Who knew?

The city of Amman is indeed one of the largest, most developed and beautiful cities I’ve ever been to. It’s very clean and tidy for a capital of a country. I was kind of surprised to not see much pedestrians walking around the town. But the roads are always full of vehicles all the time (even at midnight). So I guess pretty much everyone owns a vehicle. I also got to see quite a number of Ferraris and Porches storming the highways. I also realized that travel costs are actually very low in Amman. You can get a taxi anywhere and travel about 4 km for 0.75 Dinars (~ 1 USD).

Amman is also full of great hotels, restaurants, cafes and various shops. Truly great place for tourism I should say. Somewhere close to down town they have a street called the ‘Rainbow Street’. The street full of night clubs, restaurants, coffee shops and book shops is a great place to go and get something to eat and chill down for a while. They also have these huge shopping malls at Amman– larger than any mall I’ve ever been to. If you ever get to the city of Amman please make some time to go and visit the Mecca mall or the City mall.

Something has to be mentioned about the people of Jordan too. They are really nice and friendly. People at Amman are always full of smiles and have nothing but nice things to say. During my short stay I was even offered a couple of lunches and one great dinner.

Unfortunately for me I didn’t actually get anytime to go and visit the real tourist hotspots in Jordan, like the city of Petra or the Dead Sea. But then again, it’s always nice to have something to look forward to.

WSO2 ESB Tips & Tricks 05: Error Handling with Sequences and Proxy Services

The job of an Enterprise Service Bus is to act as the backbone of an organization’s SOA. It is the spine through which all the systems and applications within the enterprise communicate with each other. At times an ESB might even help to integrate internal systems with external applications so that complex cross cutting business tasks such as supply chain management and customer relationship management can be carried out with precision and in perfect synchronism. As such an ESB often has to deal with many wire level protocols, messaging standards and remote APIs. But applications and networks are full of errors. Applications often crash due to various bugs. Network routers and links often get into states where they cannot pass messages through with the expected efficiency. These error conditions are very likely to cause a fault or trigger a runtime exception in the ESB. A good ESB should provide simple yet powerful mechanisms for dealing with such errors. So today, I’m going to discuss a little bit about error handling options provided in WSO2 ESB.

WSO2 ESB gives you the concept of fault sequences. A fault sequence is just like any other sequence, a collection of mediators. A fault sequence can be associated with another sequence or a proxy service. When the sequence or the proxy service encounters an error during mediation or while forwarding a message out, the message which triggered the error will be delegated to the specified fault sequence. Using the available mediators we can log the erroneous message, forward it to a special error tracking service, send a SOAP fault back to the client indicating the error or even send a mail to the system admin. It is not mandatory to associate each sequence and proxy service with a fault sequence. In situations where a fault sequence is not specified explicitly, a default fault sequence will be used to handle errors. Sample 4 in WSO2 ESB documentation shows how to specify a fault sequence with a regular mediation sequence.

Whenever an error occurs in WSO2 ESB, the mediation engine attempts to provide as much information as possible on the error to the user. This is done by initializing a set of property values on the erroneous message. These properties are:

• ERROR_CODE
• ERROR_MESSAGE
• ERROR_DETAIL
• ERROR_EXCEPTION

Within the fault sequence we can access these property values using the get-property XPath function. Sample 4 uses the log mediator as follows to log the actual error message:

<log level="custom">
  <property name="text" value="An unexpected error occured"/>
  <property name="message" expression="get-property('ERROR_MESSAGE')"/>       
</log>

Note how the ERROR_MESSAGE property is being used to get the error message text. You can also write special custom mediators for error handling tasks. In such cases you can use the MessageContext API to retrieve above mentioned property values from the message.

String errorMsg = (String) messageContext.getProperty(“ERROR_MESSAGE”);

Exception e = (Exception) messageContext.getProperty(“ERROR_EXCEPTION”);

WSO2 ESB also makes it possible to send a SOAP fault back to the client whenever an exception occurs in the ESB. This is done using the makeFault mediator. The makeFault mediator converts the current message into a SOAP fault. The user can specify the error code and the reason statement to be included in the fault message. Once the SOAP fault is constructed it can be sent to the client using the send mediator. Sample 5 in WSO2 ESB documentation shows exactly how to do this. Here’s the makeFault mediator configuration from sample 5:

<makefault>
  <code value="tns:Receiver" xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/>           
  <reason expression="get-property('ERROR_MESSAGE')"/>
</makefault>

Note how the ERROR_MESSAGE property is used to set the original error message as the reason phrase of the SOAP fault. Keep in mind that the makeFault mediator only converts the message into a fault message. To send it to a client or an endpoint you need to use the send mediator. In sample 5 we mark the message as a response using the property mediator and invoke the send mediator so that it is sent back to the client which sent the original request.

Assume you want to send an E-Mail to the system admin whenever the ESB encounters an error. How do you do it? You simply need to enable the mail transport sender in the ESB configuration (by editing the axis2.xml file or using the UI). Configure the transport sender with the appropriate mail server settings. Then in your fault sequence you can simply use the send mediator as follows to send an E-Mail out.

<property name="Subject" value="An Error Occurred in the ESB" scope="transport"/>
<property name="OUT_ONLY" value="true"/>
<send>   
  <endpoint>       
     <address uri=”mailto:admin@yourdomain.com”/>
  </endpoint>
</send>

So these are the error handling options available for sequences and proxy services in WSO2 ESB. It also provides some more error handling options for endpoints. That however is a different matter entirely and hence I’m leaving it for a future blog post.

Apache Attacks: A Real Eye Opener

It seems year 2010 is gradually turning into the year of cyber crimes. The year started off with news reports on a very sophisticated and targeted attack on Google corporate infrastructure. According to Google, the attackers were successful in stealing valuable intellectual property. Now after about four months from the Google incident, a massive attack has been carried out on the Apache Software Foundation. Attackers have exploited a previously unknown vulnerability in the Atlassian JIRA instance used by the ASF, to gain root access to the server hosting the JIRA instance. Attackers also messed up the JIRA instance to install some sniffers that can capture and log user passwords. According to the Apache infra team a whole bunch of user passwords have been compromised as a result of the attack. This attack was later followed by another attack, this time directly on the Atlassian IT infrastructure, which has also exploited the same security hole in JIRA.

The Apache infra team did a pretty amazing job to mitigate the threat and take control of the situation. They have also taken some additional security measures to prevent such disasters in the future while Atlassian has rolled out patches for the aforementioned security hole.

It is hard to imagine what makes somebody attack the ASF IT infrastructure. The whole world knows that we are just doing non-profit, voluntary work at ASF. Nobody gains a monetary benefit by attacking the ASF. May be it is just to compromise the passwords and get to the users/committers. Most people use the same password to login to multiple systems (Gmail, Facebook, Yahoo, Hotmail etc). So if the attacker can get the password for one system, he can gain access to all the other systems.

All in all, this incident is a real eye opener to all of us surfing the Internet. No system is 100% safe and no system is invulnerable. An attacker with sufficient patience and skill will always find a way in. It is up to the users to be careful and minimize the chance of something horrible happening.

Moral of the Story:

We should use multiple passwords to login to different systems as much as possible. We should use strong passwords at all times. And we should definitely change the passwords in a regular basis to mitigate the effects of a possible brute force attack. (We hear these stuff everyday but how many of us actually do it? That's the problem. We should actually put these guidelines into action.)

PS: If you are an Apache committer and did not change the JIRA password yet, please do it NOW!!!

WSO2 ESB Tips & Tricks 04: Troubleshooting JMS

WSO2 ESB works really well with JMS. The JMS transport adapter used by WSO2 ESB comes from the Apache Axis2 project and it makes use of JNDI to connect to various JMS brokers. Therefore WSO2 ESB can work with pretty much any JMS broker that offers JNDI support. The product ships with sample configurations for Apache ActiveMQ integration, but it can be easily modified for integration with a JMS broker like IBM MQ or SwiftMQ.

Enabling JMS in WSO2 ESB is a simple 2-step process.

1. Deploy the JMS client libraries to the repository/components/lib directory (these libraries will be used by the ESB to connect to the JMS broker)
2. Enable JMS transport receiver and the sender by modifying the axis2.xml file or using the management console

Having followed the above mentioned process you can start creating JMS endpoints to forward messages and JMS proxy services to receive messages. However while implementing certain JMS related scenarios you might run into some error conditions. The rest of this blog post focuses on a couple of such commonly encountered problems and how to get rid of them, once and for all.

CNF? NCDF?

If you ever run into any ClassNotFoundExceptions or NoClassDefFoundExceptions while using JMS support in WSO2 ESB, chances are you haven’t deployed all the required client libraries. Please inspect what you have copied into repository/components/lib directory and make sure the required class is available in one of the deployed jars.

Also note that WSO2 ESB ships with geronimo-jms library which contains the javax.jms packages. Therefore you do not have to deploy them again.

HTTP Header Conversion Problem

When forwarding HTTP traffic to a JMS queue using WSO2 ESB, you might at times run into an error similar to the one given below.

ERROR JMSSender Error creating a JMS message from the axis message context

javax.jms.MessageFormatException: MQJMS1058: Invalid message property name: Content-Type

This exception is thrown by the JMS client libraries used to connect with your JMS broker and the problem is specific to the JMS broker being used. I have encountered this issue mostly with IBM Websphere MQ, but I guess there might be other broker implementations that may display the same issue. So here’s what happens….

The incoming HTTP message contains a bunch of HTTP headers that contain the ‘-‘ character. Some notable examples are ‘Content-length’ header and the ‘Transfer-encoding’ header. When ESB attempts to forward the message over JMS it sets the headers of the incoming message to the outgoing JMS message as JMS properties. According to the JMS spec the ‘-‘ character is prohibited in JMS property names. Some JMS brokers like ActiveMQ do not strictly check for this and hence they won’t complain. But certain other brokers will throw exceptions similar to the one shown above.

Even though the problem sounds very complex and tricky the solution is almost trivial. We just need to get rid of the troublemaking HTTP headers from the message before it is delivered over JMS. You can make use of the property mediator as follows to achieve this:

<property action="remove" name="Content-Length" scope="transport">
<property action="remove" name="Accept-Encoding" scope="transport">
<property action="remove" name="User-Agent" scope="transport">
<property action="remove" name="Content-Type" scope="transport">

JMS Property Data Type Mismatch

Sometimes when the ESB attempts to forwards a message over JMS, the client libraries may complain, saying that the data type of a particular message property is invalid. You may often run into this problem if you are using the property mediator to manipulate property values set on the message. This is because certain implementations of JMS, have restrictions on data types of properties. The property mediator always sets property values as strings.

To overcome this problem you will have to revise your mediation sequences and avoid manipulating property values which should contain non-string values. If you must set a non-string property value you will have to write a simple custom mediator to get the job done. Starting from WSO2 ESB 3.0 (scheduled to go out this month), the property mediator is type aware. Therefore to get rid of this problem you can set properties with specific data types. For an example if you want to set a property named foo with the integer value 12345 use the property mediator as follows:

<property name="foo" value="12345" type="INTEGER" scope="transport/">

If you leave the type attribute out the property value will be set as a string.

Too Many Threads? Out of Memory?

With certain JMS brokers WSO2 ESB tends to spawn new worker threads indefinitely until it runs out of memory and crashes. I have observed this behavior with SwiftMQ. This problem is caused by a bug in the underlying Axis2 engine and there is a simple workaround to the problem. In your mediation sequence engage the property mediator as follows:

<property action="remove" name="transportNonBlocking" scope="axis2">

This will prevent the ESB from creating new worker threads unlimitedly and everything will be back to normal. Note that you can always use a JMX client like jconsole to monitor the active threads and memory consumption of the ESB.

"I See You"

I saw it and it’s a beauty!

Went to see Avatar last week with some friends, and I got only two words about the movie – “Frikkin Awesome”. It’s undoubtedly one of the best movies I’ve ever watched and definitely the best movie I’ve watched in last couple of years. Everything about Avatar is so fascinating. The plot, sceneries, special effects, music and just about everything else is near perfection. I also liked the message that movie attempts to give. Avatar is about people who are at the two ends of the spectrum. On one end we have people who are willing to engage in dirty act, commit any crime, kill anyone and destroy anything to earn a quick buck. On the other end of the spectrum there are people who are willing to sacrifice their lives to defend what is considered correct and uphold the moral values. The movie takes you through the conflict between these two types of people.

If you still didn’t watch it you are not even a person. So make haste. It’s science fiction and fantasy at their very best. Also please do yourselves a favor by watching it on the big screen in a real theatre, rather than watching it on your home theatre system.

Mr. James Cameron sir, you are a genius. Thank you loads to the actors and the behind screen team of Avatar for the great entertainment. And congratulations on breaking the record previously held by Return of the King for the second highest-grossing movie ever. With the way things have been going, may be even the first place (which is currently held by Titanic) is a possibility right now.