Log/Handle exceptions in ProtonTransport.handleSocketBuffer

[calohmn]

We just had a case where there was a bug in one of our onUpdated handlers used in ProtonSender#send(Message message, Handler<ProtonDelivery> onUpdated). The handler threw an exception although it shouldn't have.

It took a while to find this bug because there was no log output of the exception. We only saw strange follow-up errors that didn't point to the original cause.

It was only when we analyzed a heap dump and found the ProtonTransport.collector to have a long list of unprocessed events (with a delivery event at its head), that we got the idea. The unprocessed events caused timeout errors, hence the follow-up errors above.

It would be helpful for ProtonTransport.handleSocketBuffer to at least log any exceptions thrown within the event-processing while loop.

I guess one could argue, that it could make sense to also set failed = true and disconnect in that case. Provided the failed handler throws the exception with each invocation, the ProtonTransport instance is unusable in that case anyway.

(I see that this issue is similar to #93, the focus in this issue here isn't on an exposed exceptionHandler though, rather it's about making ProtonTransport more robust and improving error logging.)

[gemmellr]

information was logged in such cases previously, by vertx-core. That looks to have changed in 3.6.0, along with behaviour around firing the core exception listeners as noted on #93.

[calohmn]

Seeing that the ProtonTransport instance really becomes broken (and a memory leak) if there is an event handler repeatably throwing an exception (as the corresponding event is not removed from the collector queue), I think there should in any case be some kind of exception handling in the handleSocketBuffer method.
The question would be, how to handle it.

I guess there are these options:

• Calling a newly defined exceptionHandler
• logging and ignoring it
• rethrowing it (provided it is not swallowed in InboundBuffer/ǸetSocketImpl anymore) - having called either collector.pop() or failed=true
• logging it and setting failed=true (=disconnect)