]
Paul Ferraro commented on WFLY-3721:
------------------------------------
I think the clearest strategy is to throw an exception. We should keep this behavior
consistent with all of the methods on CommandDispatcher. This also draws a clear
distinction between a sender exceptions vs receiver-specific exceptions, the latter of
which are exposed by the ExecutionException thrown by Future.get() or
CommandResponse.get().
CommandDispatcher hides exceptions
----------------------------------
Key: WFLY-3721
URL:
https://issues.jboss.org/browse/WFLY-3721
Project: WildFly
Issue Type: Enhancement
Security Level: Public(Everyone can see)
Components: Clustering
Affects Versions: 8.1.0.Final
Reporter: Rich DiCroce
Assignee: Paul Ferraro
The implementations of CommandDispatcher#submitOnCluster and #executeOnCluster completely
hide any exceptions that occur while trying to send the command. This makes it very
difficult to debug things like serialization exceptions. (Note: In the 8.x branch, the
implementation is in ServiceCommandDispatcher. In master, it has moved to
ChannelCommandDispatcher, but the code is essentially the same and the issue still
exists.)
Instead of hiding the exception, the implementation should expose the exception to the
developer in some way. A couple possibilities:
- Don't catch the exception.
- Catch the exception and return a Map with one entry, where the key is the local node
and the value is a Future or CommandResponse that contains the exception.
- Catch the exception and return an empty map, but also log the exception.