The new 1.1 release of ActiveMQ can be downloaded from the usual place...
http://activemq.codehaus.org/Download

This release represents a major increase in functionality; the new features in this release are:-

* distributed queues and topics and clusters of message brokers
* auto-reconnection of clients across a cluster of brokers
* support for high performance non-durable queues
* wildcard support on queues (as well as topics)
* transaction log and JDBC persistence in addition to JDBM and BDB
* JNDI support for easy integration
* HTTP tunnelling support
* auto-broker discovery using Zeroconf (Apple Rendezvous) for a peer based network using high performance pointcast
* composite destinations support (allowing a publish or subscribe operation on several queues and/or topics in one atomic operation, such as writing to N queues in one operation)
* simpler pure-Java configuration API
* heaps of bug fixes and new test cases

For a more detailed view of new features and bug fixes, see the release notes

Congratulations, James!

I do have a question: How easy is it to plug custom JMS solutions into app servers these days, such that transactions work correctly etc.? For example, could someone use ActiveMQ for clustered topics and use the app server's JMS impl for other topics and queues? And have it all work seamlessly? Pardon my ignorance, but I just haven't been able to keep up with this stuff at all, and I'd like to understand how well the integration is supported.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Congratulations, James!

Thanks! :)

I do have a question: How easy is it to plug custom JMS solutions into app servers these days, such that transactions work correctly etc.?

For J2EE 1.4 application servers like Geronimo and JBoss 4, you can just deploy a JMS provider as a RAR (JCA Resource Adapter) which then will just work with the JCA & transaction infrastructure of the app server.

For solutions using JMS (e.g. some custom MessageListener code) then MDBs are the J2EE approved way. (We hope to have a simple alternative soon in Spring).

For example, could someone use ActiveMQ for clustered topics and use the app server's JMS impl for other topics and queues? And have it all work seamlessly?

Sure. And you could bridge both JMS networks easily with a few trivial MDBs. If you really wanted, you could do XA transactions across both the app servers JMS and ActiveMQ all inside any J2EE 1.4 app server and it should all just work. (Famous last words :)

James
Protique
Enteprise Open Source

is ActiveMQ CTS compliant? how serious are JMS vendors about CTS compliance?
seems like JMS provider to provider integration is left to the user for the
most part with no real standard (spec doesn't mandate it either) vendor based
implementation/hooks---in my experience most vendors are shying away from
seamless integration of foriegn JMS providers in a distributed env. Does
ActiveMQ have a bridge/adapter for seamless integration or do we have to
implement that?

is ActiveMQ CTS compliant?

Due the the J2EE licensee NDA I can't say too much on the subject other than we are running ActiveMQ through the J2EE TCK compliance test suite and it doesn't quite pass. Though we are absolutely committed to being 100% compliant and J2EE certified.

how serious are JMS vendors about CTS compliance?seems like JMS provider to provider integration is left to the user for themost part with no real standard (spec doesn't mandate it either) vendor based implementation/hooks---in my experience most vendors are shying away from seamless integration of foriegn JMS providers in a distributed env. Does ActiveMQ have a bridge/adapter for seamless integration or do we have to implement that?

We provide various transports right now and its on our roadmap to provide seamless bridges into foreign JMS provders - but its not there yet I'm afraid. So we will totally have a bridge; its just not there yet.

However writing an MDB to bridge from one JMS to another is pretty simple to do. Though I take your point, end users should not have to do this.

James
Protique
Enteprise Open Source

For example, could someone use ActiveMQ for clustered topics and use the app server's JMS impl for other topics and queues? And have it all work seamlessly? Pardon my ignorance, but I just haven't been able to keep up with this stuff at all, and I'd like to understand how well the integration is supported.

In my experience it works pretty well. It is no harder to use multiple JMS implementations than to use multiple data sources. Just deploy them (in JBoss at least deploying the built-in one is trivial, with WebSphere 4 it was pretty hard), register the factories and destinations with the app server JNDI under different names, and have your code look them up (perhaps through references if you *gasp* use EJB). Not as neat as with auto-discovery, but when you have more than one to choose from it's nice to have good control.

I have just set up ActiveMQ to run within Tomcat, configured using Spring, and it works a treat - simple, lightweight and reliable. Haven't looked at clustering yet though.

Many thanks to James and all involved.

Greg,

Software Architect,
Evolution Technology Ltd.

WebSphere is pretty good about it. A lot of work was done on this for 5.0. You can plug in any JMS compliant provider to WAS. WAS also implements ASF support for improved performance if the provider implements ASF.

Billy

If you don’t need XA, it is “easy”. You just have to deploy external JMS factories in JNDI prior their use. You can usually do it in a start-up class.

Integrating external JMS inside application server isn’t as trivial as it should be, if you want XA support in J2EE 1.3.
It is “easy” to send, but quite complex to receive in MDB inside a XA transaction. Because the JMS receive transaction is started prior the application server XA transaction, these transaction aren’t correlated by default in J2EE 1.3.

But many application servers are only J2EE 1.3 compliant. J2EE 1.3 includes the norms JMS 1.0.2b and J2EE Connector 1.0. There is a limitation in these norms, which prevents to use asynchronous handling in distributed transactions in a standard way. This limitation is addressed in J2EE version 1.4. J2EE 1.4 includes norms JMS 1.1 and J2EE Connector 1.5.

Therefore with J2EE 1.3 the asynchronous handling can de done via the implementation of a specific method used to join the JMS and the post XA transaction. It is up to the external JMS provider to implement this application server specific method. If the external JMS doesn’t, then application server may poll with a code like
do
  Start an XA transaction of duration t
  Jms receive for duration t/2
  If no message rollback
  In case of message call the EJB
while (running)

Then you have casual issues with XA deployment, you may need extra patches if you want the recovery to really work, or if you want the application server to survive a JMS crash and restart…

Moreover in some J2EE 1.3 servers, this part of the documentation isn’t crystal clear.

In J2EE 1.4 it should be easy, but I didn't tried. And the JMS provider I'd like to use isn't JMS 1.1 ready.

Regards,

Stephane Lemaire