Rajith’s Column

Danushka Menikkumbura has got AMQP support going for Axis2/C via the Apache Qpid project.
This will only work on Linux as the Qpid c++ client so far has only a Linux implementation. Currently there is ongoing work from two contributors trying to port the code base to support Windows and Solaris. This is scoped for the M3 release.

Watch the WSO2 blog space or the Axis2/C website for a tutorial/blog post from Danushka.

I have tested the following with Axis2 1.4 release and the up comming Synapse 1.2 release.

Documentation is broken into two sections.
It is important to read and understand the pros and cons for each option.

If you have any questions/suggestions please post on qpid-users@incubator.apache.org
And/Or open a JIRA at http://issues.apache.org/jira/browse/qpid
Your feedback is most welcomed.

1. Configuring the JMS transport using Apache Qpid M2.1 release.
   • This version is the latest stable release and supports the 0-9 version of the AMQP protocol.
   • You can download it from here
   • It is recomended that you use the Java broker.
   • This is the recomended production version.
2. Configuring the JMS transport using Apache Qpid trunk. (with the usual caveat that it is a less stable and a moving target).
   • The trunk supports the 0-10 version of the AMQP protocol and the next release is M3.
   • You can build it from source. https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid
   • Has the following enchancements in the JMS client over M2.1
     1. You can specify multiple binding keys per destination. i.e you could bind a queue to a particular exchange using several binding keys there by allowing you to listen from multiple sources.
     2. You can bind your queue to any exchange type using the binding URL.
     3. You can set the following options per JMS connection.
        • maxprefetch - The maximum number of pre-fetched messages per destination
        • sync_persistence - When true, a sync command is sent after every persistent message to guarantee that it has been received by the broker.
     4. A new blocking transport (as an alternative to MINA) that gives much better latency, memory and increased throughput in many cases.
     5. Currently only the c++ broker supports the 0-10 version and only works on linux.
     6. In the pipeline
        • Java Broker - expected to be in M3 release. Currently being refactored
        • C++ broker - solaris and windows port are in progress (likely to be in M3 release)

1.0 Configuring the JMS transport using Apache Qpid M2.1 release

• 1.1 Qpid provides a convinient properties file based JNDI mechanism.
  • For provider URL please specify the location of the jndi.properties file.
  • The following link provides documentation for the jndi.properties file. JNDI How To
  • The connection URL format is given here. Connection URL format

  
<parameter name="myTopicConnectionFactory">
<parameter name="java.naming.factory.initial">org.apache.qpid.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">file:///opt/workspace/sandbox/axis2-1.4</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName">TopicConnectionFactory</parameter>
</parameter>


• 1.2 If you didn’t specify a custom destination for your service via the “transport.jms.Destination” parameter then the JMS transport will create a queue with the service name as its name. In AMQP world the above translates as follows. A queue will be created with service name as its name and will be bound to the amq.direct exchange with service name as the routing key
• 1.3 If you specify a custom destination name via transport.jms.Destination in your services.xml then Qpid will look that up in the jndi.properties file and create queue based on the definition given in the file.
  The binding URL format is given here. Binding URL format

2.0 Configuring the JMS transport using Apache Qpid trunk
In addition to whats described above you can do the following.

• 2.1 Specifing multiple binding keys per destination
  
  destination.wetherServiceQueue=topic://amq.topic/WeatherQueue?bindingkey='weather.us.*'&bindingkey='weather.ca.*'
  
  The above will create a queue named WeatherQueue and will bind it to amq.topic with ‘weather.us.*’ and ‘weather.ca.*’ as the binding keys. The broker will then route any messages that matches the above patterns into WeatherQueue.
• 2.2 Binding your queue to any exchange type the broker supports by using the binding URL.
  
For example if you want to bind your queue to a fanout exchange
destination.top10StockQueue=fanout://amq.fanout/WeatherQueue

  
• 2.3 Setting prefetch limit and sync_persistence per JMS connection
  
  amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672'&maxprefetch=2000&sync_persistence=true

  
• 2.4 Using the new transport
  
  Set -Dtransport=io when starting Axis2 or Synapse.

Read the rest of this entry »

Axis2 1.3 release has experimental clustering support enabling you to deploy your services in a cluster for Scalability, Failover support and HA. In simple terms, we provide replication for Service Context, Service Group Context and ConfigurationContext. This enables you to deploy your services in a cluster and share state. Please give it a spin and provide feedback via the mailing lists.
Please check the Axis2 Clustering Guide for a good introduction.

In Summary, here are a few points worth remembering

• For Stateful Web Services it is recommended to deploy in pairs using the primary/secondary model. i.e Each Node will replicate to one or more backups (secondary nodes) for failover.
• There will be only one active node at any given time. This is to avoid conflicts as we don’t have a distributed locking mechanism.
• To achieve Scalability, you need to deploy several of these pairs. In other words your cluster will consist of multiple pairs with one active node in each - and your pairs are isolated sub groups with no replication between them.
• If your cluster consists of more than one pair, you need to use some sort of partitioning to avoid a user being serviced by more than one pair within a given session in order to avoid potential conflicts. You could use session affinity to achieve this.
• There is no such restriction for Stateless Web Services.
• If your Services read shared state more frequently and update very rarely, you could experiment with more than one active node. However conflicts are still possible.

Sanjiva asked me to help over a year ago and it got postponed month after month due to other commitments until I was finally able to produce a prototype. Many thanks to Afkam Azeez, Chamikara, Snajay and Sanjiva for the support they provided. Azeez and Chamikara was primarily responsible for bringing the clustering support to it’s current state after I contributed an initial implementation. If not for those two it would have been next to impossible to get it included in the release. Special thanks to Philip Hanik for answering questions on Apache Tribes even while on vacation.

The recent posts by Paul, Dims and Dan have provided benchmarks pitting Axis2 vs XFire. I think that is a very good step and provides end users some good information. Also I would like if everybody provided the source code for these tests so non believers and end users can run it for themselves.

However, racist ranting with no performance numbers to back it up is not acceptable at all. If a person cannot explain a technical argument without subjecting him self to such a low level, then I don’t think the rest of world should care.

Dan I welcome your effort to work out the performance numbers. That is the right approach. Healthy competition will only promote WS-* and help dispell the myth that SOAP is slow. If either Axis2 or XFire is slow in this round then let the respective teams make sure that they make an effort to beat the other in the next round. Now that is whats going to make each other better, not unwarranted racist comments that shows your sorry upbringing and publicly disgracing your parents.

However Dan I believe that most enteprise systems do care about RM and Security (Addressing too). So there will be SOAPHeaders. With more SOAP stacks supporting these specs there will be an increase in the adoption of these standards in the enterprise world and so IMHO the SOAPHeaders should be part of the performance tests. However I also recognize the need for being efficient in the POX case too. As Dan said the POX use case maybe a popular one with SME’s. If Axis2 is lagging behind in that area then we as a team can work on the performance.

As for Hani, he is still motivated to spew out his garbage for the very same reason why Howard Stern is still in business. There is and will always be an audience for these type of people. Some would call it “Freedom of expression”, others like me would see it as an abuse of the that very sacred principle.

I wrote a Case Study for Synapse and it’s available here