Durable Subscription: Difference between revisions

From Open Rail Data Wiki
No edit summary
m categorisation
Line 22: Line 22:


If your client disconnects and reconnects, the service will automatically send all queued messages when you reconnect.
If your client disconnects and reconnects, the service will automatically send all queued messages when you reconnect.
[[Category:Network Rail Data Feeds]]

Revision as of 08:58, 20 May 2013

What is a Durable Subscription?

"A durable subscription saves messages for an inactive subscriber and delivers these saved messages when the subscriber reconnects. In this way, a subscriber will not lose any messages even though it disconnected. A durable subscription has no effect on the behaviour of the subscriber or the messaging system while the subscriber is active (e.g., connected). A connected subscriber acts the same whether its subscription is durable or non-durable. The difference is in how the messaging system behaves when the subscriber is disconnected." -- http://www.eaipatterns.com/DurableSubscription.html

Why Should I use One?

You may occasionally disconnect from the Datafeeds service - your client may crash, you may experience connectivity problems or you might simply need to reboot a machine. A durable subscription stops you losing messages when you're not connected:

  • The TD and Train Movements feeds are high-volume, and if you disconnect for even a minute, you can lose a lot of data
  • The VSTP feed contains new schedules, and if you miss one of these, you can't track that train
  • The TSR feed has a handful of messages on a Friday morning (when the Weekly Operating Notice is published)

The Time-to-Live (TTL) on messages is 5 minutes. As long as you reconnect within 5 minutes from your last connection, on your next connection, you will receive all messages that you may have missed whilst your client was offline.

How do I Request a Durable Subscription?

You don't need to rewrite your client! Just do these three things:

  • When you send a CONNECT frame, send a client-id in the header. Set this to the email address you use to subscribe - this makes it easy to identify who the durable subscriber belongs to
  • When you send a SUBSCRIBE frame, send a activemq.subscriptionName header. Set this to a unique string for each feed - for example, the hostname of your subscriber and the feed name, e.g. "prodbox-vstp"
  • Each time you receive a message, send an ACK so the service knows you've received it

If your client disconnects and reconnects, the service will automatically send all queued messages when you reconnect.