Archive for September, 2007

The First Impression

I’m using WSF/C in a project and here is some useful tips that we used in out project that may help WSF/ C more attractive to the linux user.

There is a standard body for File System Hierarchy Standard for Unix-like operating systems. We followed that standard and make our components install to these standard places. For example our libraries go to /opt/wso2/lib, our logging goes to /var/log/opt/wso2/x.log etc. The idea is by making it to standard places one who uses it intuitively know where to look for certain files and also make it all easy to provide standard packages like rpm and deb packages. There are many other advantages as you can see in


Other thing is decide on how to break up the distribution into several packages. Instead of distributing a one big rpm or deb package we can break it into several packages and the interested user will download and install only the components he is interested. He can always download and install other components as required. For example in providing rpm’s we can give util rpm, axiom rpm, core rpm and even apache module rpm, xmpp transport rpm etc. Also we can provided dev rpm’s test rpms etc. Of course we need to put a dependancy on util rpm in core rpm etc. Also the default installation should include minimum useful set of rpm’s(same apply for debs).

We can provide a set of test rpm’s which enable the user to immediately make sure that everything goes on well in a very short time. In the work I’m doing I have a collection of axis2c services for various purposes. In my tests I deploy these services in the engine, start the engine as an apache module and send some client requests against these services and then show the success/failure of these tests using CUnit at client side. All this is done by running a single CUnit test file.

rpm -i <wsfc package>

rpm -i <product component 1>

rpm -i <product component 2>

rpm -i <product component 3>

rpm -i <test suite>


That’s all the user need to do to test soe product components. This also make it easy to write good scripts to automate the things.

Read Full Post »

Great Team Work

I had the greatest teamwork experience during our off-season journey to Sri Pada couple of weeks back. Our team consisted of Kaushalya, Nandika, SanjayaR, Dinesh, Dushshantha, Amila, My brother in law(Upul) and Me. We choose the route along Kuruwita which is the longest(11.5km) and the most difficult of the three main roads leading to the the top. We set out early in Saturday morning hoping to comeback in Sunday evening and make it to the office by Monday morning. In the off-season the stoney steps are wowen with moss which cause a slippery serface slowing the progress. It was about 7pm when we make it to the top finally. We spent the night in a hired room with minimum facility of some mats on the cold floor. But we were lucky to watch the sun rise in the early morning which I must say is a very rare experience which only you can enjoy freely only in the off-season. But the problem in the off-season is that you are often prevented from seeing it by clouds and mist but in our case we were lucky. When we set out the return journey it was sunny all over the mountain range but at the middle of the journey heavy rain began to pour down. We were all equiped with rain coats so it did not hinder our progress, but the danger was awaiting us!.

Amila, Dinesh and Upul Aiya lead rest by about 20 minutes and they managed to cross Seetha Gangula before us. Seetha Gangula is a small river across the Sri pada path. It is about 30 meter’s wide and normally you can wade it with water upto your knees.

But by the time rest of us reach it, it began to overflow making it difficult to cross. Infront of our eyes the water level was rising rapidly so we decided to stay in the Ambalama nearby(Ambalama is the sinhala name to the resting place for people to use for rest in long journeys) . Luckily there was Ambalam in both side of the river. I think this was built on purpose because the rising of water is a usual thing to happen and people caught in it can stay on these Ambalama’s until the water level reduce.

Nature has done a nice separation between us on the two banks. All the matchbox and lighter was with us. Firewood was with them!!!. Raw Noodles we took with us to cook for lunch were with us but the pot to cook with was with them!!!. So SanjayaR, Kaushalya, Nandika, Dushshyantha and me who were trapped in this side had nothing to do, but pray for the Rain to stop. The time was 1pm. There was no sign of stopping the rain. There was a great chance that we may have to spend the night there. There were no signals to our phones so that we could not inform our families that we may get delayed. It was unimaginable to stay the night with no food and in the cold and dump Ambalama. We need a fire somehow!!!. All were hopeless for some time and everybody looked bewildered. But slowly but gradually the team started to get it’s spirit back thanks to Sanjaya who managed to make some fire by using small leftover’s of some firewood and papers. But how we are going to keep that fire going?. I remembered one of my previous similar experience and knew that wet logs can be make good wirewood if we can dry them for some time in fire. So Kaushalya and me collected a good amount of wet logs from around the Ambalama. That worked very well and after some strenuos effort we were having a good fireplace promising to give warmth for a whole night. Now we are warm next problem is food. Then Nandika came with that great innovation of making a pot using some left overs of a rectangular Aluminum sheet which he managed somehow to find from within the Ambalama. So we managed to cook the noodles using his primitive age cook pot. I have never enjoyed such delicious noodles !!!.

By the time the rain stoped it was about 8pm. The rain was so heavily pouring non-stop for about 8 hours!!!. For water level of the water to reduce it took about another two hours. By the time we crossed the river it was 10pm.

We managed to come to the office by Monday 2pm.

Read Full Post »

An Axis2 C design issue?

There was this discussion between Sanjaya Karunasena, Samisa and me regarding the application/session scope supported by Axis2 C engine when it is deployed as an Apache module.

The problem that initiated the discussion is as following. In Savan C(The WS Eventing Specification implementation of Axis2 C web services Frame Work) when a subscriber send a subscription message to a Data Source, that data source maintain the subscriber’s state in a hashmap stored in one of it’s service parameter. So the next time the subscriber send a Renew Subscription message or a GetStatus message or a Unsubscribe message to the data source, that subscriber’s identity is updated accordingly in the service parameter’s hashmap.

This scenario works as expected when axis2 C is deployed as an axis2c stanalone server. But when Axis2 C is deployed as an Apache Module this does not work. I will explain it as following. when a request comes to a Axis2 C service, the Apache web server serves it in a thread spawn from a certain process. The next reqeust from the same requester for the same service may be served by a different thread from the same process or a different thread from a completely different process spawned by Apache2 to increase the performance. When a new process is spawned by Apache the Axis2c module’s init module function is called for that process, resulting in a new Axis2 C configuration context. A new configuration context means a new serivce context!!!. Now all the state stored in the earlier process’s service parameter is lost in this new service context’s service. Because of this problem the subscription information stored in the hashmap of the datasource service’s parameter in the subscription request may be lost when another request comes regarding the state of the subscription.

To solve this problem what I did is to store the subscriber’s state to a database. But Sanjaya’s argument was this is a hack the developer has to provide because of the Axis2 C engine’s inability to maintain the application or session scope as it promise. But Samisa argued back saying that it’s wrong of Apache2 to init the Axis2 each time it serve the new request. But Sanjaya is saying that still we should be able to do some inter process communication to keep the session or application scope as required. He proposed to do a multicasting as it is done in gmond applications to propogate the state between the machines in which the gmond is running. He proposed that this same solution can be extended when it comes to load balancing support in Axis2 C.

It was also discussed to find out how other Apache module developer’s who need to maintain state between module instances do this. For example how PHP do this? The discussion ended agreeing to start a discussion thread on this.

Read Full Post »