E.g. RequestCorrelator.sendRequest() eats the exception (try-catch clause), this has consequences, e.g. when an argument is not serializable, we'd simply log the exception and the caller would wait forever for the responses (although the request was never sent).
Brian's email:
In all AS Clustering use cases, JGroups' RpcDispatcher is used, which in
turn uses a RequestCorrelator. Looks like a try/catch block in
RequestCorrelator.sendRequest() is swallowing any Throwable that is
thrown when it pushes a message into the channel, only logging a
warning. If async semantics are in place, the calling application will
never know there was a problem. (Haven't checked but probably with sync
semantics the calling application will think that no responses to the
message were received, when actually the issue is the message was never
sent.)

Was working on a case (https://na1.salesforce.com/50030000001nxk9AAA)
where it looks like the user is experiencing
http://jira.jboss.com/jira/browse/JGRP-179. JGRP-179 deals with
situations where something like an OOM condition caused a message to not
be added to the NAKACK retransmission table. I was wondering why there
was no logging of the underlying error condition. Their protocol stack
had no down threads, so any Throwable would bubble up to the above
referenced try/catch block.

A lot of people disable WARN logging, so it wouldn't surprise me if this
kind of problem is often not logged.

Brian Stansberry