aspose file tools*
The moose likes Distributed Java and the fly likes Queues or Topics ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Queues or Topics ?" Watch "Queues or Topics ?" New topic
Author

Queues or Topics ?

Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 491
    
    1

Hi there,

I'd like to get some advice from you on choosing between queues and topics. Scenario: i have some Java swing based client which need to be notified by remote application server when certain events occour.
I thought to use a JMS MTOM and let client to connect directly to it. Since notifications must be sent only to specif user(s), I wondering which choice would be the best, considerating that:

- an user may login on different PCs with same userid at the same time, and may be desiderable to get all clients to be notified;
- notifications must be persistent.

Possibile choices:

- create a topic for each logged user (it doesn't sound good, too many resources may be needed).
- create a single topic with different durable subscribers (each per user; other connections with same userid would be accepted but they would be created as durable)
- create a queue, but as far as I know a queue delivers it messages only to a single, first fetcher listener.

Can you help me please ?




Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40

Claude Moore wrote:
I'd like to get some advice from you on choosing between queues and topics.


Topics and queues are different quality of services. Topics are for pub/sub. Publishers publish on a topic. Subscribers subscribe on a topic. And all subscribers on the topic are supposed to get *all* the messages from all the publishers on the topic.

Queues are, of course, for queuing. Producers write into the queue. Consumers read from the queue. And there is a guarantee of once and only once delivery. In general, a common use case for queuing is load-balancing -- for cases, when a single consuming application can't process all of the messages in a message stream.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 491
    
    1

Thanks for your reply, Henry, and for your clarifications. So, I'd say that queues shoudl be discarded in my scenario, I'll use topics.
At this point I've to study how manage durable subscriptions from multiple workstations with same user id.

Thank you again.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40


Claude Moore wrote:
- notifications must be persistent.


Persistence is merely the broker (or another entity for cases where the messaging environment is broker-less) saving the messages (most commonly in some sort of file). These messages can then be called upon later for recovery, when a subscriber "returns" to the message stream -- meaning if the subscriber dies, and then get restarted, it needs to get all the messages that it missed.

Persistence can also apply to queuing, but the consumer doesn't really care too much about it. In that case, persistence is more for when the broker dies (which may trigger a fail-over) -- meaning when the broker is restarted (or the replacement broker takes over), it needs to obtain all the messages that hasn't been delivered yet.

Claude Moore wrote:Thanks for your reply, Henry, and for your clarifications. So, I'd say that queues shoudl be discarded in my scenario, I'll use topics.
At this point I've to study how manage durable subscriptions from multiple workstations with same user id.


Interestingly, durability is for pub/sub only. With queuing, messages are delivered once and only once, so once a consumer acknowledges delivery, the broker/queue is done with it. There is no need to have identity for the consumers. The broker/queue is only concerned with delivering the message to a consumer.

For pub/sub, identity is very important. Durable publishers and subscribers must be tracked. When a subscriber acknowledges a message, the broker needs to persist that state. When a subscriber dies, and is then restarted, the identity of the subscriber is used to negotiate the subscriber's position in the stream, so that the subscriber can recover all the messages that it missed.

In summary, persistence, durability, along with a bunch of other stuff (like HA / DR setups) are used to accomplish "guaranteed delivery" of messaging.


Anyway, what is my point? Keep in mind that the identity of the subscriber is for the messaging environment only. It is for the messaging environment to use to tell subscribers apart, and to know that a previously dead subscriber has now returned. A common mistake is to use application specific data (such as user id) for the identity of the subscriber. Be careful with that. While your application don't mind having the same user log in from different locations simultaneously, messaging environments don't like it when the "same" subscriber is connected to the broker (for the reasons mentioned).

Henry
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 491
    
    1

Henry,
If I were a rancher i'd have gave you a cow for your clear, concise, and neat explanation... so accept a simple thumb up.

While your application don't mind having the same user log in from different locations simultaneously, messaging environments don't like it when the "same" subscriber is connected to the broker (for the reasons mentioned).


I made some experiments with Apache MQ. At least for that MTOM, I observed this behaviour:

- if you try and create a durable topic subscription with a given ID, and the topic subscription has not been created yet or has been created before, but it isn't active, it is created and / or passes to an active / connected stated;
- if you try and create a durable topic subscriptio with a given ID, and the ID is already in use, an exception is propagated to the client. Exception keeps track of the fact that same ID is already active, so I can make distinction
between attempts to use same ID and other errors (like networking errors).

I may use this behaviour this way: if i cannot connect due to an error like "ID already connected", i may subscribe to the same topic in a non-durable manner, implying that all login after the very first of the day are only "volatile".
This way an user should be always notified by MTOM.

The problem is I don't know if this behaviour is implementation-specific.

What do you think about ?


Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40

Claude Moore wrote:
- if you try and create a durable topic subscriptio with a given ID, and the ID is already in use, an exception is propagated to the client. Exception keeps track of the fact that same ID is already active, so I can make distinction
between attempts to use same ID and other errors (like networking errors).

I may use this behaviour this way: if i cannot connect due to an error like "ID already connected", i may subscribe to the same topic in a non-durable manner, implying that all login after the very first of the day are only "volatile".
This way an user should be always notified by MTOM.

The problem is I don't know if this behaviour is implementation-specific.

What do you think about ?


I don't use JMS enough to know the subtleties regarding this. For work, I generally use the native API, even when I am working in Java... but yes, it is a configuration detail. If a subscriber tries to use an identity that is currently in use, the messaging environment can either generate an error condition, or allow the new subscriber to take the subscription from the previous subscriber.

Henry
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Queues or Topics ?