June 16th, 2008 |
Published in
AMQP, Axis2, Qpid | Add to del.icio.us
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.
June 8th, 2008 |
Published in
AMQP, Axis2, Qpid, Synapse | Add to del.icio.us
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.
- 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.
- 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
- 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.
- You can bind your queue to any exchange type using the binding URL.
- 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.
- A new blocking transport (as an alternative to MINA) that gives much better latency, memory and increased throughput in many cases.
- Currently only the c++ broker supports the 0-10 version and only works on linux.
- 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
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 »