Transient fault handling and retry policies

baywet commented 7 years ago

Hi, We're approaching production deployment for our service which relies on this library (against S4B Online). It appears that the UCWA is not the most reliable API at the moment, we haven't implemented any kind of retry policies or transient error handling in our code so far. We're often getting errors like

InvalidOperationException
'{"code":"Gone","subcode":"TooManyApplications","message":"You\u0027ve been disconnected because your most recent sign in exceeded the server limit."}'

Or ServiceFailure (probably because connectivity to server dropped). Looking at the code here I can't see any transient fault handling or retry policies implemented so far. So here are my questions:

Did I miss something?
Is anybody working on that at the moment?
Would you be interested in a PR around that? (I'd like to open the discussion around where and how to handle such errors before actually writing some code)

kenakamu commented 7 years ago

I think there may be some threshold for how many applications it can create or input per seconds? The best place to handle errors are inside client where HttpClient sends Post message.

baywet commented 7 years ago

From my experience (but I can't find any official documentation about that) it's a maximum number of "applications" currently connected, and it's generally around 5 per account. I was thinking about implementing the following policy: in case of a gone code, disconnect, wait 1 sec, reconnect, retry. (with an exponential timing increase) Do you think it should be done differently? What parameter should we provide to the consumers of the SDK?

kenakamu commented 6 years ago

Implemented by @baywet

kenakamu commented 6 years ago

published as version 1.0.7

kenakamu / UCWA2.0-CS

Transient fault handling and retry policies #27