Normally, TransportException instances are effectively IO related exceptions, except that they're runtime versions instead of checked exceptions. If there's an IO exception coming from a node, I think it makes sense to clean up all connections to that server.

There's an exception here, and that is when `pool.borrowObject()` throws an exception (i.e. TransportObjectFactory.makeObject threw an exception), which get laundered into TransportException instances.

For IO related exceptions, you do have a Transport instance that you can invalidate, but not for the latter since the Transport instance was not created (or failed to be created), unless you send it back in the exception itself.

All these exceptions though are rather exceptional in that they're not linked to application level errors (except in in the initial ping sent to the server when Transport instances are created), so I'm not convinced by your argument.

I disagree with calling invalidateTransport when RemoteNodeSuspectException is encountered. This exception refers to a node different to the one sent back the error. It indicates this other node was suspected. There's nothing wrong with the node that returned the error. The problem is with another node.