As of April 12th, you must go to Progress SupportLink to create new support cases or to access existing cases. Please, bookmark the SupportLink URL and use the new portal to contact the support team.
We are using the Titanium javascript library and are using promises for interactions to Kinvey. We see occasional network timeouts on real devices, and have added logic outside of the promise functionality to handle the most critical situations (by wrapping our Kinvey.DataStore.find/.save/etc calls in a function that returns the promise and then using a method that will recreate and retry the promise if it is rejected for a network timeout). In a lot of situations (most actually), we have chained promises. Obviously, trying to convert all of these Kinvey transactions to being wrapped in a function (so we can re-create a rejected promise) would be time consuming, but worse I think it would clutter up the code and add a lot of complexity--and I can't imagine we are the first project to encounter this problem but I haven't been able to find a good solution searching the web.
So, is there a best-practice design for retrying promises due to failed network timeouts? Ideally, it would be able to re-send a network request for a certain number of retries, preferably defined when the promise is created...? I've come up with some ideas, but 1) I doubt they are good practice (try to modify the underlying promise object) and 2) I'm struggling figure out what the underlying promise library even is that is connected through the adapter.
Thanks in advance,
Jack
1 Comment
M
Mark
said
almost 9 years ago
As the library doesn’t have a `retry` option, the nicest solution is to wrap a call in a function like below. This allows you to define a specific number of retries to specific calls to Kinvey.
else {// Not a timeout, or no more retries. Propagate error.
throw error;
}
};
var promise = ping().then(function(result) {
// result will be the network response, after max. 5 retries.
});
```
If you want to do this for *every* request to Kinvey, you could "hack" the libraries `Kinvey.Persistence.Net._request` method, which is used to build HTTP requests. I normally don’t recommend this, but if it would be easier than wrapping the functions, you could do it.
Jack Vargo
We are using the Titanium javascript library and are using promises for interactions to Kinvey. We see occasional network timeouts on real devices, and have added logic outside of the promise functionality to handle the most critical situations (by wrapping our Kinvey.DataStore.find/.save/etc calls in a function that returns the promise and then using a method that will recreate and retry the promise if it is rejected for a network timeout). In a lot of situations (most actually), we have chained promises. Obviously, trying to convert all of these Kinvey transactions to being wrapped in a function (so we can re-create a rejected promise) would be time consuming, but worse I think it would clutter up the code and add a lot of complexity--and I can't imagine we are the first project to encounter this problem but I haven't been able to find a good solution searching the web.
So, is there a best-practice design for retrying promises due to failed network timeouts? Ideally, it would be able to re-send a network request for a certain number of retries, preferably defined when the promise is created...? I've come up with some ideas, but 1) I doubt they are good practice (try to modify the underlying promise object) and 2) I'm struggling figure out what the underlying promise library even is that is connected through the adapter.
Thanks in advance,
Jack