• Post Reply Bookmark Topic Watch Topic
  • New Topic

JMS puzzle

 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is anyone really familiar with how real Java Message System (JMS) systems are implemented, or can try some stuff out?

I'm having trouble getting my head round the semantics of the interaction between MessageConsumer.receive and MessageConsumer.setMessageListener;

MessageConsumer.receive allows code to ask a Queue/Topic if a message is available, or block until one is. The JMS 1.1 spec states:


A client can request the next message from a MessageConsumer using one of its receive methods. There are several variations of receive that allow a client to poll or wait for the next message.


MessageConsumer.setMessageListener allows code to sign up to be notified immediately a message arrives. The JMS 1.1 spec states:

A client can register an object that implements the JMS MessageListener interface with a MessageConsumer. As messages arrive for the consumer, provider delivers them by calling the listener�s onMessage method.


But what happens if my code does neither?

If only MessageConsumer.receive were supported, it would make sense for the MessageConsumer to internally store messages until the next time MessageConsumer.receive is called.

If only MessageConsumer.setMessageListener were supported it would make sense for the MessageConsumer to discard messages if no listener is registered.

If the MessageConsumer has just been set up and does not know which access method the calling code is going to use, what should it do with incoming messages? store or discard?

If some messages have been stored in the MessageConsumer in case MessageConsumer.receive is going to be called, but the receiving code registers a listener instead, should it immediately get all the stored messages in one blurt?

And what happens if my code does both?

If I have a listener registered, will it "eat" all the incoming messages so no messages will ever be available to MessageConsumer.receive? If I have a MessageConsumer.receive currently blocked and waiting for a message will it get an incoming message before, after, or as well as a registered listener?

I was really surprised that I couldn't find the semantics of any of this in the spec. Has anyone got any experience of how this actually works in real implementations?

Thanks.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In general I think that most of these things depend on your messaging provider, and on how it's been configured. Messaging systems and products existed before JMS interfaces came along as a means to somewhat standardize access to them, and for better or worse many details can still be vendor-specific. The potential benefit is that this gives vendors more options to optimize their systems for particular characteristics. The downside of course is that there's no one easy answer to your questions - you probably need to read teh docs for whatever provider you're using. Or test it and see. Note that there may well be additional configuration you can perform which can change the behavior. And it can make a difference whether you use queues or topics, and whether subscribers are durable.

I should note that I don't have a great deal of experience with different messaging systems, so these answers are not by any means authoritative. But offhand, I'd expect that for a queue or a topic with durable subscribers, messages will accumulate somewhere (in memory, or backed by a filesystem or DB) until they are successfully received or they expire. (If an expiration has been set.) For any nondurable topic subscribers... eh, messages will probably persist somewhere for a bit, as after all anyone using receive() can't be expected to be calling that method every nanosecond. There's got to be some way for newly arrived messages to wait in memory for... a bit... (he said vaguely). But at some point undelivered messages (for nondurable subscribers) can just get dropped. How & when that happens is up to the implementation.

Hope that's some help...
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!