SwiftMQ no more freely available

[schulert]

Hello all!

How deep is the SwiftMQ JMS Router/Server involved into the JBOSS project? And what are saying about SwiftMQ's decision that version 3.0 and following aren't freely available any more?

On februara 17th SwiftMQ annouced that the SwiftMQ Router became commercial and the licenses of the free downloaded version of 3.0 and further are revoked.
See www.swiftmq.com

[nphelps]

SwiftMQ 3.0 will integrate with Jboss, but that’s as far as it goes. There is no 'business relationship' that I know of between the two. In other words, when you download Jboss, there is not SwiftMQ code at all. Jboss uses it own JbossMQ internally which is open source just like the rest of the Jboss stack. SwiftMQ has previously been free, but never open source. Anyway, that is the extent of it. I've long been a user of SwiftMQ because I need the support for federated router networks which no open source implementation seems to support that I know of. My hopes are now pinned on JbossMQ.

[hchirino]

Wana help build the federated network features???

I mean how hard can it be??? The main thing we need is a router process. When the server got a message that needs to go to some other node in the federation, it dumps the message in the router's queue.

The router process picks up the message looks at routing configuration and dumps the message to the right queue that a channel is working on. A channel is nothing more than a process that moves messages from one node in the federation to another node.

Most of the work will NOT be in the JBossMQ core. It will be in the router and channel processes.

Regards,
Hiram

[nphelps]

Let's see, tell me how this sounds...

We could create a org.jboss.mq.RoutingListenerServiceMBean and a org.jboss.mq.RoutingConnectorServiceMBean that could provide a socket connection between two or more JbossMQ instances. Then we could register a JMX listener and listen when queues/topics are created and send out notifications to the other JbossMQ instances. Does this sound like a good start? We'd have to change the way we name queues in this arrangement because queues become dependant on the instance they are defined upon. So testQueue would have to become testQueue@routerinstancename. I never really liked that about SwiftMQ, but I don't think there is any way around it. Thoughts?

[hchirino]

Sounds good to me! If you need any features added to the JBossMQ core let me know.

Regards,
Hiram

[camtabor]

Hey,
I just wanted to mention that I am about to start using SwiftMQ for JMS. As much as I hate to do bring in a foreign MQ provider, it just has a few features that we see as necessary. The main one being that with JBoss MQ I was never able to get messages to be redelivered from a remote message queue after a shutdown of the MDB container. The messages that were being processed simply sat in file persistence forever.
I will watch JBossMQ closely and will jump at the chance to go back to using it. To the developers of JBossMQ, great work, I know it won't be long before it can do what I mentioned and more. The above suggestion about connecting MQ instances together (like Swift) is a GREAT idea.
-Cameron

[pra]

This works in 3.0 as far as I know, I and will - if possible - do a backport. Soon, any day now, I just have to solve this threading bug I introduced...;-)

//Peter

[camtabor]

Hmm, I tried this in 3.0 and was still unable to get it to work.

Steps:
1) Start Remote MQ.
2) Start MDB Container
3) Send messages to be consumed. (our messages take @ 1 minute each to process)
4) Shut down the MDB Container in the middle of processing.
5) Restart MDB container.

The messages that never started processing will be consumed just fine, but the ones that were already started will sit there indefinitely.
The workaround is to restart the Remote Queue, which is not acceptable. Please correct me if I'm wrong about this, I'll certainly give it another look.
Again, this is a small issue, and other than this one thing I am very pleased with the JBossMQ, and you can't beat the price!
-Cameron

[pra]

Hi, correct me if I am wrong, but is this what you are doing:

- One or more messages are beeing processed in the beans onMessage (i.e they are recieved by the bean), and you shut down the bean in the middle of its work?

- If I am correct: what type of TX settings do you use.

(Hiram, when the session/connection is closed should not all messages that have been consumed, but not yet acked be "rolled back"?).

//Peter

[camtabor]

That is exactly right, I'm using Transaction Required for the MDB's. I'll try this again to make sure I'm not mistaken here. I wouldn't want you spending your time trying to fix something that's not broke.
-Cameron

[cptnkirk]

It's been a while since I've poked around in the JBossMQ code (but I may pick it up again). I'd love for jboss to have federation support, and would consider contributing. Before you get too far along I'd like to talk a little about some functional reqs.

Seems from the posts that we all know and love (or at least accept) the federation system used by Swift. From what I can tell the system has the following features...

1. "Physical" JMS resources are provided in the form of resourceName@routerInstanceName.

2. A higher level meta representation allows various physical resources to be combined into a single JNDI resource.

3. Routers develop a network topology based on a RIP like protocol (routers can connect to and/or listen for connections from other routers). This allows the meta JNDI layer to change (because of updates/deletions by peer routers) without effecting the JMS clients.

4. Messages are sent from a JMS client to a router, which then, based on a number of hopefully pluggable modules, can then provide support for routing messages to waiting consumers.

Some features that aren't supported, but would be nice to have...

1. Support for router failover within the JNDI object. If configured, the current or possibly a subset of the available network can be remembered by the JNDI object when it is sent to the JMS client. In a typical case with Swift, even if you have a federated network, if the router you're connected to goes down, you need to connect to another router that is capable of providing the meta JNDI resource you once had on your last router. Currently you're forced to keep track of this on every client, or make sure your client and router fail at the same time. The latter is suggested, and running a router on every client isn't impossible. However there are resource and other considerations that could prevent this on some deployments. I'd really like this feature as it would eliminate some configuration hassles on the client, as well as that single point of failure.


Ok, that's what I've got. There are also a few people in the clustering forum that may have some ideas as to what they'd like to see provided with JBoss' JMS federation. I'll try and point them to this discussion. Of course we may want to start another topic since this really doesn't fall under the topic of SwiftMQ being freely available.