So I was wondering about a problem. Consider a publisher creates a topic at 10:00 am and immediately starts publishing messages on to the topic. It notifies the consumers of creation of the topic and then they subscribe to the topic at 10:01 am. These consumers will not receive messages sent by the publishers between 10:00 am - 10:01 am. So should the messaging provider immediately discard these messages if it finds that there are no active subscribers for this topic to receive any messages. Can we provide a subscription mechanism by which consumers can specify from which point they want to receive messages, (for eg. from the start of the topic or 12/25/2011 10:00 am PST etc.)
In Publish/Subscribe messaging model, publisher does not notify creation of a topic to subscribers.
Publishers and Subscribers are loosely coupled via the topic. So a publisher will not know whether there are any subscribers or not. Messaging provider discards a publication on topic if there are no subscribers for that topic. Some messaging providers inform the publisher if there are no takers for publication. This way publisher can make a decision on whether to continue publishing or not.
Subscribers will start getting publication from the time when a subscription is created. There are two types of subscriptions, durable and non-durable. Non-durable subscriptions are the ones where publications are delivered to subscribers as long as they are active. Durable subscription is the one where publication are delivered even when the subscribers are not active.
There is concept of Retain Publication where in messaging provider retains one latest publication and delivers to subscribers who join late.
Related
I have a topic. I have 10 consumers subscribed for it. As per my understanding, a message will be removed from
topic when all consumers have received it. Right? Once it is removed, any further subscriber
will not be notified for that specific message. I could not confirm this in the JMS specification anywhere.
A broker (in your case Active MQ) will deliver a publication to all active subscribers, both durable and non-durable (meaning consumer applications which are running when a publication was made on a topic and consuming messages and any durable subscribers which are not active). The broker will then discard the publication. If there are no active subscribers or durable subscribers for a topic, the broker will discard the publication immediately. It will not wait for any subscribers to become active. The only exception is in the case of "Retained Publication" option being exercised, where the broker will cache a publication and deliver to consumers who may arrive later. But note that broker will not wait for all consumers to receive publication before removing it from a topic. I would say there is nothing like 'removing from topic'.
Hope I am clear.
Only active subscribers will get your message in that case, after that your message is removed.
If you want to send your message also to inactive subscribers you can configure durable subscription.
I am new to JMS. I have started with "hello world" where I am publishing the message from java application on Topic and
listening it from client (node.js Javascript). I have gone through this wikipedia entry, but I have some questions based on my previous theoretical understanding.
As per my understanding, point-to-point is the queue implementation where there can be at most one consumer subscribed on queue and can
be consumed by that only. Neither producer nor the consumer knows about each other. Queue is hosted on message brokers in my case Apache ActiveMQ. Queue can be created by producer before publishing the message (or it can be created from console in advance).
In case of publish/subscribe model, it's almost same as point-to-point except the fact we use Topic instead of queue. In this model there can be more than more consumer on the topic. Once the message is published, all the subscribers will be notified. Now if any of the subscriber, send the acknowledgment for the published message, message will taken as consumed and it will no longer be available for new subscriber?
Point to Point means message(s) is sent from one application(producer or sender) to another application(consumer/receiver) via a queue. There can be more than one consumer listening on a queue but only one of them will be get the message. Hence it is Point to Point or One to One.
On the other hand Publish/Subscribe is another messaging model where a message(or publication as it is commonly called) is sent to multiple consumers(or subscribers) through a topic. The topic is the link between publisher and subscriber. The subscribers may or may not acknowledge the published message. Implementations like JMS acknowledge the message the messaging providers but not the sender of the message. Publications will be received by all subscribers, durable and non-durable. Any new subscribers on the same topic will not get the publication unless it is a Retained publication.
I would recommend you to read further on,
Durable subscription
Non-durable subscription
Retained publication
I am struggling to understand Durable subscription. I understand that when a Listener registers itself as a Durable Subscriber to a Topic, it tells JMS - "Hey, I am durable subscriber, from now onwards you need to store all the messages in Topic if I am not there and pass me those messages when I come back"
Now, if that's the case, why can't two subscribers ask for this durable subscription?
Am I missing something?
Quoting from the Java EE tutorial
A durable subscriber registers a durable subscription by specifying a
unique identity that is retained by the JMS provider. Subsequent
subscriber objects that have the same identity resume the subscription
in the state in which it was left by the preceding subscriber. If a
durable subscription has no active subscriber, the JMS provider
retains the subscription’s messages until they are received by the
subscription or until they expire.
To make durable subscriptions work for multiple subscribers on 1 durable subscription the broker would have to store each individual message from the creation of the topic (by the first-ever subscriber) until its expiry, ie potentially forever if no message TTL is specified, because at any point in time a new subscriber can pop in and claim all the messages it "missed" (that is, all messages since the subscription was created). That's just not feasible.
I may be missing the point here, but I can't see how having multiple simultaneous subscribers sharing a subscription would be more practical than defining two separate subscriptions?
The understanding of Duplicate Durable Subscription is incorrect.
Durable subscription does not mean that no multiple subscribers can subscribe. It means no One subscriber can have two different identifiers for durable.
I want to understand a thing: When a durable subscriber is activated on a topic, in add on this topic there is another subscriber (mdb). Is possible that the durable subscriber take the messages and don't provide it to the MDB?
Thanks a lot..
When a message is sent to a topic, by intent there's a separation between the publisher and the consumers.
Although there are ways you can create transactional delivery around sending to all consumers, there's no way a consumer can take a message and prevent other consumers from receiving a message as well.
I am trying to find an answer on of how to notify an EMS Publisher in case of a Subscriber failure.
In a case of Publisher->EMS server->Subscriber, if a Subscriber fails, I need to inform Publisher to take a corrective action.I am not bothered about durabilty/PERSIETENCE, my significance is of time. In Trading systems, If I send an market order to a Subscriber who in turn sends it to an exchange, if it fails, I need to make my Publisher publish the messages on a different topic to another Sunscriber(another exchange).
Any ideas is appreciated.
The tibjmsadmin.jar library contains methods to detect when subscribers disconnect. Easier than writing code, you can:
if you have Hawk, use the
tibjmsadmin.hma to write a Hawk rule
in the event a subscriber
disconnects, or
listen on the monitor
topic
$sys.monitor.connection.disconnect -
the body of the message tells you
which subscriber disconnected.
However these "monitoring" approaches to failing over the publisher have a significant problem - in the time it takes for you to detect the subscriber failure and redirect the publisher, some messages may get through and get stuck in the defunct queue. You don't wat this happening to any $10M trades!
EMS knows when subscribers are connected or not and you should take advantage of this.
Use a "distributed queue" and there shouldn't be any need to code logic into your application to switch to a new subscriber when it fails. This happens without message loss and maintains the order of messages. It is also good architectural practice to keep load balancing and failover logic out of your code and in the administration setup of your JMS provider.
Basically you setup multiple subscribers to a queue (each exchange represented by a subscriber). The default action will be for EMS to load-balance messages across your subscribers in a round-robin fashion. But you can set the queue to "exclusive" so that messages go to only one subscriber at a time. Then if that active subscriber fails, the messages are forwarded to another subscriber.
See the EMS manual for more details on all these topics.
Not sure if you have access, you could try looking at the ReceiverCount or ConsumerCount in either QueueInfo or TopicInfo - I believe you need the tibjms.admin package. May be you can query this before you publish and then selectively publish? Not sure what the overhead is.
Because of the nature of JMS, AFAIK no transaction states (unless you use a XA transaction - with all of that overhead) or acknowledgements will propagate through the EMS broker. I.e.acks are always between publisher and broker and consumer and broker.
Failing the above, you could try a separate ack topic for which the roles are reversed, but then the failure case is a timeout - I'm not sure this is sensible.
If you don't really care which exchange the order goes to - why not make the topic/queue exclusive and make both consumers attempt to consume - the first one to succeed will process all of the messages - if it dies, then the second one (which could be periodically retrying - may successfully connect).. Alternatively allow both to process orders off the queue - remember a message will only be ever processed by a single consumer...
I really cannot see the advantage of a decoupled messaging bus in your order flow... makes no sense to me..