• Should send()/dispatch() really be executed as part of the Retry work job along with connect()?
• What stops retry policy executing numerous times when the exception is simple a transformer issue (TransformerException)?
• If retry fails because of a transformer exception for example how to we avoid throwing a somewhat confusing FatalConnectException?
• If we no long wrap exceptions in FatalConnectException in AsbtractRetryTemplate and just throw the cause then we we wouldn't be differentiating between simple connect exceptions and fatal exceptions caused when retry policies are exhausted which doesn't sound ideal.
• AbstractRetryTemplate is supposed to be generic so shouldn't be throwing a FatalConnectException but rather a RetryStrategyExhaustedException. This could then be wrapped in ConnectException by the callee.

It looks like either send()/dispatch() shouldn't be inside retry callback, or if they are there by design then we need a way in which to determine which exception types should result in the retry policy being executed and which exception types should not, rather causing retry loop to end and throwing the exception up (e.g. TransformerException)

Update (Dan F)
I've taken a closer look at the code and I really can't see why we have retry callbacks being used in for example AsbtractMessageDispatcher send()/dispatch() for reconnection. The connect() already uses a retry callback/work item to connect, so by implementing another one here we actually giving send/dispatch/receive retry functionality. I assume this is by design even though it's more just an improvement implementation of reconnection strategies. If this is the case we need to make this change clear in documentation so users know that the retry policy they configure is used for connect, dispatch, send and receive and any implications of this. Also I still think we need to think a bit more about what types of exceptions should/shouldn't result in retry in all of these cases.