Re-implement retry

[slandelle]

Retry currently introspect Exception stacktrace to decide if it can be recovered or nor. This is very expensive and probably error prone.

We could decide that:

• user Exceptions, like those thrown by Handler methods or when reading a File that's to be uploaded can NOT be recovered => wrap them in UnrecoverableException
• other Exception can be recovered

@jfarcand WDYT?

[jfarcand]

@slandelle Agree, but keep in mind I used introspect because of error used library...now since we only have Netty this is a good idea to revisit.

[slandelle]

@jfarcand The thing is I don't really understand which exceptions can be retried and which cannot, except for user ones. And I suspect you don't remember either ;-)

So, I'm tempted to says that all Exceptions but user ones can be retried and build from that. Anyway, we can't use error messages and the ones coming from the OS are localized on Windows...

[jfarcand]

@slandelle NIO exception from nowhere...those are easily reproducible (or were) on OS X when you get Selector freaking spin or unexpected exception. But the NIO implementation might have improved as the code was written 5 years ago.

[slandelle]

@jfarcand IIRC, the Selector spin issue happens mostly on Windows, and Netty has a workaround that can be configured with a System prop. Anyway, if it happens, retrying or not is not a primary concern, as you probably have to kill the AHC instance.

Let's go with my suggestion, and let's wait for user feedback.

[jfarcand]

@slandelle You will regret this ;-)

[slandelle]

@jfarcand Why? Do you have an example of an Exception where you don't want to retry and where retrying would really be harmful?

[jfarcand]

@slandelle Somewhere in the commit history I'm sure I've listed some...will check.