Durable Subscription: Difference between revisions
PeterHicks (talk | contribs) m Added details of the TTL on messages |
EvelynSnow (talk | contribs) those STOMP spec links should be github.io not github.com |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== What is a Durable Subscription? == | |||
== What | |||
"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 | "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 | == 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: | 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: | ||
| Line 11: | Line 9: | ||
* The [[TD]] and [[Train_Movements|Train Movements]] feeds are high-volume, and if you disconnect for even a minute, you can lose a lot of data | * The [[TD]] and [[Train_Movements|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 [[VSTP]] feed contains new schedules, and if you miss one of these, you can't track that train | ||
* The [[TSR]] | * 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. | 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 | == How do I Request a Durable Subscription? == | ||
You don't need to rewrite your client! Just do these three things: | You don't need to rewrite your client! Just do these three things: | ||
* When you send a [http://stomp.github. | * When you send a [http://stomp.github.io/stomp-specification-1.1.html#CONNECT_or_STOMP_Frame 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 [http://stomp.github. | * When you send a [http://stomp.github.io/stomp-specification-1.1.html#SUBSCRIBE 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 [http://stomp.github. | * Each time you receive a message, send an [http://stomp.github.io/stomp-specification-1.1.html#ACK 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. | If your client disconnects and reconnects, the service will automatically send all queued messages when you reconnect. | ||
{{Navtable-DataFeeds}} | |||
[[Category:Network Rail Data Feeds]] | |||
Latest revision as of 16:36, 19 November 2024
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.
| Network Rail Open Data Feeds | |
|---|---|
| Data Feeds | About the Feeds • Account States • Durable Subscriptions • Example Code ( PHP / C# / Java / Ruby / Node.js) • Advanced Uses • FAQ • Release Notes |
| RTPPM | RTPPM Feed |
| Train Movements | Train Movements Feed • Train Activation • Train Cancellation • Train Movement • Train Reinstatement • Change of Origin • Change of Identity • Change of Location • TSPEED Field • Planned Cancellations • Cancellation Codes |
| TD | TD Feed • C-Class Messages • S-Class Messages • Train Describers • TD Berths |
| VSTP | VSTP Feed |
| TSR | TSR Feed • Route Codes |
| SCHEDULE | SCHEDULE Feed • TIPLOC Records • Schedule and Location Records • Association Records • CIF Codes • How Scheduling Works • Allowances |
| Reference Data | Reference Data Feed • TOC Codes • CIF Codes • Delay Attribution Codes • Identifying Locations (STANOX, TIPLOC, NLC and 3-Alpha Codes) • STANOX Geographical Areas • Train Planning data (BPLAN) |