Multicast JMS

[ggimler]

In an attempt to create a multicast publish/subscribe topic, I followed the code example at http://www.jboss.org/developers/projects/jboss/jms/documentation/pure-p2p

I'm getting really inconsistent results running a simple producer and consumer.

Sometimes my consumer never receives any messages sent, other times it receives a subset but never all of them. I have sleep statements to make sure I first have my consumer listen and then the producer sends the messages at a 1hz rate.


I'm pretty sure I configured things properly (at least everything that was mentioned at the URL). I know this code has no claims it's bug-free but it's essential I get this working.

There were no exceptions seen on the JBoss console window or any error logs. Is there any updated documentation on this feature of JBoss? I think the article was written several months ago and might be dated to the current implementation.


I've attached my own output at the bottom. Any help on this would be much appreciated. Thank you.



I'm using JBoss-4.0.0DR2 and my output screen is the following:


[java] -------------------------------------------------------
[java] GMS: address is 155.34.129.129:2389
[java] -------------------------------------------------------

[java] -------------------------------------------------------
[java] GMS: address is 155.34.129.129:2391
[java] -------------------------------------------------------

[java] -------------------------------------------------------
[java] GMS: address is 155.34.129.129:2393
[java] -------------------------------------------------------

[java] -------------------------------------------------------
[java] GMS: address is 155.34.129.129:2395
[java] -------------------------------------------------------
[java] [TopicSendClient] sent a message.
[java] [TopicRecvClient] waiting for messages.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicRecvClient] Got a message
[java] org.jboss.jms.TextMessageImpl@5973ea
[java] [TopicRecvClient] Got a message
[java] org.jboss.jms.TextMessageImpl@c9131c
[java] [TopicRecvClient] Got a message
[java] org.jboss.jms.TextMessageImpl@105b99f
[java] [TopicSendClient] sent a message.
[java] [TopicRecvClient] Got a message
[java] org.jboss.jms.TextMessageImpl@ce2187
[java] [TopicSendClient] sent a message.
[java] [TopicRecvClient] Got a message
[java] org.jboss.jms.TextMessageImpl@fb56b1
[java] [TopicSendClient] sent a message.
[java] [TopicRecvClient] Got a message
[java] org.jboss.jms.TextMessageImpl@f8968f
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.


[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.
[java] [TopicSendClient] sent a message.

[ggimler]

Nevermind. Looks like the Synch client was what I wanted. However, I'm still wondering if I'm using multicast or not. This GMS output with addresses not in the multicast range lead me to believe I'm not multicasting. Is there some way to turn this on in the jgroups configuration? Thanks.

[belaban]

Don't use the old impl; Ovidiu is working on a new implementation. He will post a first prototype in 1-2 weeks (I'm actually playing with it as we speak).

Bela

[ggimler]

Thanks for the quick reply. What can I expect in this new implementation? Will true hardware multicast be available with the JMS? When can I expect an officially stable release?

Am I currently multicasting with that old version? Can I get some documentation?

[belaban]

// Thanks for the quick reply. What can I expect in this
// new implementation?

A first prototype will be out next week. Depends on Ovidius schedule.

// Will true hardware multicast be available with the
// JMS?

Yes, as one of JGroups' configuration options.

// When can I expect an officially stable release?

What features do you need. This prototype has
- pubsub (topics)
- queues

It does not yet have support for
- TXs
- persistent msgs/durable subscriptions

Ovidiu ?

[ovidiuexternal]

I will probably release 0.2 next week. That means Mar 15-19.

0.1.1 is a standalone prototype and it's not really public yet. It doesn't rely on JBoss in any way. You can publish/subscribe to topics and send/receive to/from queues, but you can only use non-persistent delivery mode. Persistent topics are not supported.

The multicast server doesn't deal yet with confirmations of any kind, it relies only the reliable multicast provided by JGroups.

The sessions can only be created as non-transactional and AUTO_ACKNOWLEDGE.

There are a lot of JMS API calls that will only throw NotImplementedException, but there is a minimal set of methods that allow you to run simple examples.

This is what I am trying to include with 0.2:
- initial support for persistent delivery
- a more solid JNDI implementation (now you can only lookup two destinations "Topic1" and "Queue1").
- reduce the number of API calls that trow NotImplementedException
- public access

[ggimler]

Excellent! I'm very encouraged there's such an active effort on this. I'm relatively new to JGroups but I've been reading more about it and it sounds like a great thing that will solve a lot of my critical issues. I need to be able to switch between sending data pub/sub with lots of many-to-many connections on a LAN via straight unreliable multicast to unreliable unicast for a WAN connection over a satellite. It seems like JMS over JGroups would allow this. Currently it seems like there's one master XML file. Do you plan on having it configurable so that one can start up multiple topics with different protocol stacks on the associated channels? Perhaps you already can and I just don't know how?

As for persistent delivery could you elaborate some more what you mean about this? Does this include some sort of fault tolerance? If the JBoss application server were to crash for some reason or get restarted would it have the capability to re-establish connectivity to any topic client producers/consumers that were sending/receiving data? If not, are there plans to add that? Thanks a lot.

[ggimler]

Is there some date in mind for releasing a non-beta version? I'm assuming 0.2 still means in the beta stage? Thanks.

[ovidiu.feodorov]

The current implementation uses only one "control channel" per Connection. All channels must be configured the same way (same stack configuration file) in order to join the group. Control traffic and payload traffic share the channel.

A very sensible idea is to use a different channel or more, with fewer protocols, for payload traffic. That's somewhere in the plan and we'll get there sooner or later. I guess this is what you mean when you say "multiple topics with different protocol stacks". The prototype doesn't support that yet.

Persistent delivery. JMS 1.1 specifies that there can be two different types of delivery, persistent and non persistent. For non persistent delivery, the client code hands over the message to the provider and send() method exits while the message is still in the provider client runtime memory, or in process of being put on the network. If the provider dies, the message is lost. For persistent delivery, the provider first stores the message to
persistent storage, and then gives gives the confirmation that it received the message for delivery, by exiting send(). If it dies, message is not lost, since it was stored, and the provider attempts re-delivery once it's back. There are plans to add that, yes. We have to, if we
want to be JMS 1.1 compliant.

0.2 means alpha stage.

When the release 1.0 will be available... I really want it to happen soon, but at this moment I cannot give an estimation that I am confident I can stick with. Hopefully the code will make its way into JBoss code base and it will be easier for me to publicly update the status of the project, the time estimations and release dates.

[ggimler]

So let me ask you this...

Is it currently possible to send that JMS through a firewall? Can I send it multicast and rebroadcast unicast and vice versa or is that impossible in the 0.2? Would there be a significant development effort to do this?

Here's what I'm thinking and perhaps what I could do is this:

Configure a producer to a topic using 1 channel via mulicast. Have a consumer connect and retrieve that data via the same protocol stack configuration. Have it then somehow send data (forward it) to another topic that would create another channel with a different protocol stack (unicast or firewall) and send it that way? Would that at least be possible to do? Can I pass in another jgroups xml file and overwrite the protocol stack...I don't have issues using another channel to do this. I just want to make sure it's possible.

[ovidiu.feodorov]

Your solution is in principle correct, and, oddly enough, almost possible to implement with the current alpha release.

Basically, you'll have to write a "bridge client", that creates two connections to two different serverless JMS providers. The first one runs over the multicast domain and the other one has a JGroups stack that uses a router or direct TCP. You'll have to write the bridging code, based on the topic name, etc.

There is a small problem with the way the connection gets its configuration information, right now is kind of hardcoded, but this is easy to fix. I'll have to change the JNDI implementation for that.

The good solution to the problem is to add bridging code to JGroup itself. This way, you won't have to send messages up and down the stack just to take a routing decision at application level. We have plans to add that, as well.

If everything works out OK, a version that supports the solution you described should be available some time next week.

[ggimler]

Sounds great! I look forward to trying this out next week. If you could give me some instructions on how/where to get the 0.2 when you release it, I would appreciate it. Thanks.

[ggimler]

Will the new version 0.2 be released today or some time next week? Perhaps it's already been released and I don't know where to look to get it?

[ovidiu.feodorov]

A version that contains everything you need to experiment with your "relaying" solution is ready to be released. I don't want to call it 0.2. Not that the name matters, anyway, but 0.2 was supposed to include persistent delivery, and I am still working on that.

I will post the URL on the forum later today. Or early tomorrow.

This is how you configure it:

Let's assume you use the machine A and B on the same LAN and they can see each other by multicast, and a machine C that is on a remote site. If your LAN is protected by a firewall, you must be able to open a port in the firewall, in this case 12003. If you use NAT, forward the port to A.

1. On A, start the JGroups' GossipRouter (you can find a jgroups.jar in the bundle, or you can compile it independently http://www.jgroups.org):

java -cp lib/jgroups-core-2.2.1.jar:lib/log4j.jar org.jgroups.stack.GossipRouter -port 12003

2. On A, have your "bridging" client look up the "RouterConnectionFactory". You configure it by modifying etc/router.xml. The only thing to change there is router_host, which is is the public IP address of A. The same client has to look up "ConnectionFactory", which provides multicast connections. Take a look at etc/jndi.properties, you'll find it self explanatory.

3. On C, look up "RouterConnectionFactory". It has to be similarily configured. Now A and C clients can exchange messages.

4. On B, look up "ConnectionFactory". Now A and B clients can exchange messages.

5 If your bridging client on A switches back and forth messages from a connection to the other, B and C can exchange messages.

This is just a proof of concept. There is no reason to have an application-level "bridging" client. The bridging between multicast and unicast will be transparently handled by JGroups. In a future version, of course.

And by the way, there's no need to write even a line of code to test what I've just explained above. Take a look at the interactive client provided with the bundle. There is a short description of how it works in the documentation. It can create JMS objects (connections, sessions, producers and consumers) at command line so you can mix and match and build your prototype.

[ovidiu.feodorov]

Release 0.1.2 is available at:

http://www.feodorov.com/tmp/sljms-0.1.2.tar.gz

The master documentation file is doc/index.html