<Should we start from scratch or refactor the existing code base?>
IMHO, it should be built from scratch, using the AOP stuff in JBoss 4.0. I recently heard Marc talk and his talk reoriented my thinking regarding the place of the J2EE spec. In other words, you want to implement the J2EE/JMS spec, but don't limit JBoss to just that. There are other ways to do messaging beside JMS !!
I think one of the drawbacks of JBossMQ (was or is)
absense of C/C++ clients and absense of adapters
to popular industry MQ as IBM's MQ Series or Tibco Rendezvous.
New implementation should take it into account
I visited http://www.ubermq.com/ and read about the UberMQ. It seems to be polished and contains many features and seems to be extremely fast because of it's use of NIO. The features on the site are:
- Based on the Java NIO library for speed and scalability
- Robust durable subscription implementation
- Customizable overflow handling
- Low latency, high throughput guaranteed messaging
- Message viewer GUI to examine your message traffic
- Pluggable wire and transport protocols
- Reliable multicast and TCP out of the box.
I'm not an expert at JMS so I think someone should check it out and tell us what they think of it. If the results are good, we should consider using it for JBoss 4.0.
How about an option to receive the last message published over a topic when you attach to it.
it looks quite reasonable. There are a few things like transacted sessions that are missing though.
I would like to see a JMS implementation that has a mechanism to get around a chained group of firewalls? What I mean is say I've got several JMS clients/servers (one per JVM) scattered behind a chain of firewalls as so:
JVM #1 <----> Firewall #1 <--> JVM #2 <--> Firewall #2 <--> JVM #3
Obviously let's assume both Firewalls allow traffic back and forth. But JVM #1 cannot directly connect to JVM #3 b/c of the chained firewalls.
Is there a way to send a message from JVM #1 to JVM #3 by having JVM #2 act as a "router"?
http://www.swiftmq.com has functionality like this but they aren't open source.
I'm actually kind of curious why something like this isn't a part of the JMS standard. Is this more of a web services kinda thing? I'd really like to see a JMS implementation like this that I can use in my intranet environment.
JMS instance federation is a feature we'd like to have. However, it is after clustering on the priority list.
Actually I just found out UberMQ supports this option around firewalls already b/c of their fault-tolerant clustering mechanism.
I am the project lead and main developer on the UberMQ project on sourceforge and I would be psyched to help you guys if you were interested in integrating my JMS implementation w/ JBoss 4.0.
It is version 2.0 right now and has some pretty solid features. It is missing some of the transaction and appserver integration features of JMS simply because I wrote it with the intention of being stand alone.
Please contact me at firstname.lastname@example.org if anyone wants to talk integration. Thanks for the kind words about my project!
I was "psyched" to discover UberMQ and after looking at the source code extensively, was keen to give it a try,.. it was actually very close to going into a production system a few weeks back, until we actually did come testing :) The solid features you talk about arent that solid, we had all kinds of problems, there are some incorrect interpretations made about the JMS specification, and in most kinds of "exceptional" circumstance it didnt fare well. Apart from that the JBoss integration was easy, and performance was great and I really liked most of the design. I just started freaking out when I had to start changing stock standard JMS client code to get things to work with UberMQ.
All in all though I would say that UberMQ would be a decent place to start for the rewrite.
Wow - sorry to hear you had such a bad experience. I use uberMQ extensively in my own projects both commercial and open-source and it's been a very solid platform for almost everything I've tried.
But of course this is probably the original developer syndrome - I know exactly how the code is written so I know exactly how to use it.
I would really appreciate it if you would take the time to let me know exactly what problems you guys were facing and maybe give me some sample code that I can use to make modifications. Hopefully you'll give it a 2nd chance in your production system when I do. ;)
First of all, I'm not the final authority on this subject. However, I do have a vested interested in the development of JMS/JBoss having just quit my job to join the JBoss Group in order to lead its development. This fact does of course color my opinion. However, I do think I can step outside of myself to become a non-biased outside observer. From that standpoint, I'll first say that you, Jimmy, deserve some accolades for developing what looks to be a good JMS implementation. Secondly, your willingness to make it available to the open source community should be commended. However, I do think the JBoss Group will continue to pursue an independent JMS project for JBoss 4.0.
This has nothing to do with the quality of UberMQ. It, on the other hand, has everything to do with the architecture of UberMQ. Like the current JBossMQ code base (based on SpiderMQ), UberMQ was developed outside the context of the JBoss group. Therefore, the architecture doesn?t share a great deal in common with the overall architecture of JBoss. This is one of the reasons why the JBoss Group decided to rewrite JBossMQ. It, like UberMQ, is a good JMS implementation. However, it, like UberMQ, isn?t built on top of the core JBoss services like CMP/JBoss AOP/JBoss, JCA/JBoss, Clustering/JBoss, Cache/JBoss, etc. Since utilizing these services is the major motivation for the new JMS/JBoss development, replacing the current JBossMQ code base with UberMQ doesn?t really buy us much. Additionally, the leadership of the JBoss Group has asserted a desire to continue to support JDK 1.3 in JBoss 4.0. UberMQ?s extensive use of the JDK 1.4 NIO package would put a wrench in that plan as well.
In summary, it is my assertion that we?ll continue going down the JMS/JBoss re-write road independent of UberMQ. The motivation for doing this has nothing to do with you, or UberMQ. Instead, it all comes down to a desire to have a tightly integrated JMS 1.1 implementation that fits into the overall JBoss architecture, and as importantly, looks like the overall JBoss architecture. There is room for more than one great open source JMS implementation, and I wish you luck as you continue to develop UberMQ.
The powers that be may have different opinions concerning this topic, and I invite them to speak up if so.
JMS/JBoss Lead Developer
No need to be sorry, IMHO UberMQ is great work,.. but you know how it is, when your balls are on the line and the deadline approaches its sometimes a good idea not to build EVERYTHING on open source :)
Ive just this minute got off a plane back from Fiji,.. im a married man now :) Ill try and get you some feedback on the actual issues we had when i manage to drag my arse back to work.