Same is true for the file storage upload call (currently line 435 in AbstractWrapper.kt). Here it makes sense to retry the upload if it fails due to network reasons. The exceptions here are quite a lot, however I added the wrote the upload method on my own in Java (due to a conflict with the object method name in the MinIOClient & the keyword in kotlin). We could just write our own Exception class that we can fill with any of the problematic exceptions from the MinIOClient & just catch our own exception in the retry.
We could also change the decorator to give it a predicate function that tests the exception. That way we could handle multiple exception types.
Could look like this:
val wpsProcess = retry<WPSProcess>(
forExceptionsOfTypes(
IOException::class.java., InterruptedException::class.java
), { it ->
return@retry WPSProcess()
})
I think in that case we could even remove the exception type parameter from that function & just catch every possible exception - that we then put into the predicate.
arnevogt
commented
1 year ago
Maybe we can add the retry also in the fetchContent method in the AbstractWrapper file.
Here we fetch the contents from the object storage - and http retry settings could be helpful as well. When I take a look at https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html then it seems that this could throw IOExceptions or InterruptedException. I guess the IOException is the better one to catch here.
Same is true for the file storage upload call (currently line 435 in AbstractWrapper.kt). Here it makes sense to retry the upload if it fails due to network reasons. The exceptions here are quite a lot, however I added the wrote the upload method on my own in Java (due to a conflict with the object method name in the MinIOClient & the keyword in kotlin). We could just write our own Exception class that we can fill with any of the problematic exceptions from the MinIOClient & just catch our own exception in the retry.
We could also change the decorator to give it a predicate function that tests the exception. That way we could handle multiple exception types.
Could look like this:
I think in that case we could even remove the exception type parameter from that function & just catch every possible exception - that we then put into the predicate.