Difference between revisions of "Good Practice"
Jump to navigation
Jump to search
(Created page with "Please bear in mind the following points when you use the service - they're here to make sure everyone gets a good service: * '''Sign up with one account''' - it gives an acc...") |
CACI Support (talk | contribs) (Updating guidance on connections) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Please bear in mind the following points when you use the service - they're here to make sure everyone gets a good service: | Please bear in mind the following points when you use the service - they're here to make sure everyone gets a good service: | ||
| − | * '''Sign up with one account''' - it gives an accurate reflection of how many people are actually using the service | + | * '''Sign up with one account''' - it gives an accurate reflection of how many people are actually using the service |
| − | * '''Connect to the service once''' - you can | + | * '''Connect to the service once''' - you can subscribe to multiple topics or queues in a single connection. Don't use separate connections for each of the feeds |
| − | * '''Don't leave a failed client running''' - if you can connect but get an authentication or authorization error - '''stop your client''' - don't leave it continually trying | + | * '''Loop on receive, not on connection''' - ensure you are only creating one connection per feed, instead of creating a new connection for each batch of messages |
| − | * '''Make sure your client handles failures''' - if your client fails to connect or is disconnected, use [http://en.wikipedia.org/wiki/Exponential_backoff an exponential backoff] and wait 1s, 2s, 4s, 8s, 16s etc. before trying to reconnect. Service problems sometimes occur, and if everyone tries to reconnect every second, the service will not recover quickly | + | * '''Use separate client ids per client''' - using the same client id on the same feed across multiple clients can lead to multiple connections being made, which may lead one of your clients to be blocked. Note that client ids are not usernames, which can be re-used across multiple feeds, client ids, or even machines. |
| − | * '''Use a durable subscriber''' - if you want data to be queued in case you disconnect, request a [[Durable Subscription|durable subscription]] when you connect | + | * '''Process messages quickly''' - messages left on the server build up and can cause problems for other users, so consider using an [[Advanced_Uses#Bridging_Topics|configure an ActiveMQ bridge]] to keep the messages under your control |
| + | * '''Don't leave a failed client running''' - if you can connect but get an authentication or authorization error - '''stop your client''' - don't leave it continually trying | ||
| + | * '''Make sure your client handles failures''' - if your client fails to connect or is disconnected, use [http://en.wikipedia.org/wiki/Exponential_backoff an exponential backoff] and wait 1s, 2s, 4s, 8s, 16s etc. before trying to reconnect. Service problems sometimes occur, and if everyone tries to reconnect every second, the service will not recover quickly | ||
| + | * '''Use a durable subscriber for topics''' - if you want data to be queued in case you disconnect, request a [[Durable Subscription|durable subscription]] for the Network Rail platform when you connect | ||
* '''Use [http://stomp.github.io/stomp-specification-1.1.html#Heart-beating Stomp heartbeats]''' to detect network problems that may otherwise leave your client hanging with no data | * '''Use [http://stomp.github.io/stomp-specification-1.1.html#Heart-beating Stomp heartbeats]''' to detect network problems that may otherwise leave your client hanging with no data | ||
| + | |||
| + | [[Category:Network Rail Data Feeds]] | ||
| + | [[Category:National Rail Enquiries Data Feeds]] | ||
Latest revision as of 13:01, 8 August 2023
Please bear in mind the following points when you use the service - they're here to make sure everyone gets a good service:
- Sign up with one account - it gives an accurate reflection of how many people are actually using the service
- Connect to the service once - you can subscribe to multiple topics or queues in a single connection. Don't use separate connections for each of the feeds
- Loop on receive, not on connection - ensure you are only creating one connection per feed, instead of creating a new connection for each batch of messages
- Use separate client ids per client - using the same client id on the same feed across multiple clients can lead to multiple connections being made, which may lead one of your clients to be blocked. Note that client ids are not usernames, which can be re-used across multiple feeds, client ids, or even machines.
- Process messages quickly - messages left on the server build up and can cause problems for other users, so consider using an configure an ActiveMQ bridge to keep the messages under your control
- Don't leave a failed client running - if you can connect but get an authentication or authorization error - stop your client - don't leave it continually trying
- Make sure your client handles failures - if your client fails to connect or is disconnected, use an exponential backoff and wait 1s, 2s, 4s, 8s, 16s etc. before trying to reconnect. Service problems sometimes occur, and if everyone tries to reconnect every second, the service will not recover quickly
- Use a durable subscriber for topics - if you want data to be queued in case you disconnect, request a durable subscription for the Network Rail platform when you connect
- Use Stomp heartbeats to detect network problems that may otherwise leave your client hanging with no data
