Handling Rate Limits (and other intermittent streaming errors)

As you are building systems, you may find that your exceeding rate limits specified by the platform. The basics of rate limiting in Initial State can be found here - API: Rate & Bandwidth Limitation. The rate limit is enforced at the per-account-level. Please let us know at contact@initialstate.com, and we can help. 

A Rate limit error can happen at any time, and can be affected by other devices send data into the same account. Therefore all production systems should consider and handle intermittent rate-limit conditions gracefully. In fact, this method can be used for other intermittent network or server failures to fail safe, fail gracefully, or ideally heal from error conditions. 

• If you can't lose data, then we recommend to use "buffer and retry" with some type of timeout to generate a critical error
• If it is OK for your system to miss data intermittently, then you can safely ignore rate limits until some saturation point in which you should generate a critical error. 

Rate Limit Error

The Initial State SDK uses LabVIEW custom errors in the 6000-6600 range. The error code corresponds to the standard HTTP Response codes, with 6000 added. For example a 404 NOT FOUND with be 6404 in LabVIEW. To handle a specific errors more generally subtract 6000 from the error code to discover the original HTTP Error Response Code.

The Rate limit error generated from Initial State is 429 Too Many Requests. It will come into LabVIEW as Error Code 6429 - {"code": "RateLimitExceeded", "status":"RATE_LIMIT_EXCEEDED","message":"Your request count (49) is over the allowed limit of 30."}

The Send VI captures that specific error and converts it to a simple boolean output, because it is common to use this error to drive a buffering system

Buffer and Retry

The Send VI has a special rate limit output and the Initial State Example - Looping.vi program found in the example finder has a simple version of using a Shift Register to buffer data and retry. 

Here is how this simple system works. 

1. Monitor the "Rate Limit Exceeded" Boolean output from the send VI. 
2. When true, ignore the output error (which will be the rate-limit error), and pass the existing JSON Cluster Array full of data into a shift register. 
3. On the next iteration combine the output of the shift register with the new data acquired by the iteration and retry. 
4. You should also create a timeout or buffer size limit and account for this case. 

Ultimately, in production you should combine this technique with a producer-consumer architecture so that networking is removed from the acquisition and UI loops. In addition, producer-consumer comes with a buffering mechanism (i.e. LabVIEW Queue), that facilitates "buffer and retry". You can see how that works in the next article.