Tuesday, March 9, 2010

Axis2 temp files

Axis2 supports archive based deployment for both services (.aar) and modules (.mar). These files can internally have 'lib' folders to contain the third party libraries of those services.
From Axis2 1.5, when Axis2 creates Configuration Context object which happens when the server starts up or service client invocation, it creates a separate folder under the temp folder to store the temp files. This temp folder is taken from the "java.io.tmpdir" system property.
For an example if Axis2 1.5 is deployed under tomcat 6.0.24, it creates the following two files under $CATALINA_TMPDIR.
axis2-tmp-2165190954418103759.tmp
axis2-tmp-2165190954418103759.tmp.lck

Axis2 creates .lck files as a temp file which deletes on a jvm exits.

File lockFile = new File(tmpDirName, tmpDir.getName() + ".lck");
lockFile.createNewFile();
lockFile.deleteOnExit();

Therefore when the tomcat goes down this .lck file should also be deleted. But the .tmp folder remains. At the next start up time Axis2 searches for .tmp file folders which does not have a corresponding .lck files and deletes them. So there can not be any grow of temp files.

One important thing to remember is that Axis2 copies the repository files (.aar and .mar) when ever it creates a configuration context object. Therefore the tmp folder can be grown while in the server running. Obviously this can be stopped by using one configuration context object for all the service invocations.

But there are some instances where .lck file is not properly deleted when the jvm exits. For those situations the temp folder can be deleted within the server starts up shell script. For tomcat this can be done adding code to catalina.sh.

Monday, March 8, 2010

Queued Transaction processing with WS-RM

Couple of years ago I started writing a new WS-RM implementation called Mercury which uses an state machine model to handle the reliability. It was working well for the requirements we had at that time and we have done two releases under the name WSO2 Mercury. But however WSO2 Mercury could not support the user initiated transactions due to a limitation of its storage design. Then that project didn't last too long and WSO2 moved to use Apache Sandesha as its WS-RM implementation for newly developed carbon based products.
At that time I was doing my Msc at University of Moratuwa. For my Msc I was looking for an idea and Dr Sanjiva Weerawarana and Mr Paul Fremantle gave me the idea of re engineering the WSO2 mercury code to support transactions by introducing a new transaction based storage API. Then I started researching different types of reliable message delivery models and finally was able to developed a WS-RM protocol which provides application to application reliability using distributed transactions. This model follows a similar pattern as the well known Queued Transaction processing and hence the thesis tile.

Here is the abstract of my Msc Thesis
With the popularity of the distributed business applications, the application data is distributed in various physical storages. However most of the business transactions require to update data stored in more than one storage. Hence updating two data storages reliably is a common problem for most of the distributed business applications.

Queued transaction processing is a concept widely used to achieve such a processing model using intermediate queues to transfer messages reliably. In such a system at the client side, both updating the client storage and writing the message to be sent to the client side message queue happens in the same distributed transaction. Similarly at the server side reading the message from the server side queue and updating the sever storage happens in the same distributed transaction. But such a system may have interoperability problems if client and server use different types of technologies.

Web services are used to communicate among the heterogeneous systems by passing SOAP messages using standard transport mechanisms like http. Web services can reliably communicate by using WS-Reliable messaging specification(WS-RM). WS-RM uses concepts of Reliable messaging source (RMS) and Reliable messaging destination (RMD) between which it guarantees reliable message delivery.

By combining these two concepts, we introduce an approach to solve the above mentioned problem in an interoperable manner using WS-RM to communicate between nodes while keeping RMS and RMD as intermediate storages. In our model reliable message delivery happens in three phases. First both updating application client storage and writing message to the RMS happens in the same distributed transaction. Then WS-RM protocol reliably transfers the message to RMD at the server side. Finally at the server reading the message from the RMD and updating the server storage happens in the same distributed transaction. The middleware software entity that we developed to encapsulate this approach is called Mercury which implements WS-RM protocol.


Msc Thesis report
CD copy which provides the source code, binaries and demos