Clarify how to handle all fatal errors

Hey,

I’ve been working on an internal library that tries to wrap the CometD Java client into a Reactor Flux. Part of this involves propagating all possible fatal events (terminal failures, server sent disconnects) as errors.

I’ve registered the necessary callbacks on handshake and subscribe as suggested in the manual - and thanks for documenting that!

The problem is that wasn’t quite enough. I’ve also had to override the BayeuxClient’s onTransportFailure(String, String, Throwable) method in order to handle fatal internal errors when there are no more transports to fall back on (eg. a handshake failure where the advice is ‘none’, or exceeding the max backoff time). I’ve also had to define an extension to handle server initiated disconnects, which while not being errors are fatal to the BayeuxClient.

If anything above seems obviously wrong or if there’s an easier way to capture all errors, please let me know. If not, I have some recommendations:

• For now, documenting the need to override onTransportFailure to handle internal issues would be awesome. The documentation already covers using callback methods to handle handshake and subscription failures, so this would fit right in. Same goes for clarifying that server sent disconnects need to be handled, and maybe even having an example of an extension that would server.
• In future versions, it might make sense to take a page from Reactor and define callback registering methods directly on the BayeuxClient. It’d be more consistent than overriding (since we already use callbacks to handle handshake/subscribe issues) and allow us to define handlers like onFatalError, onTerminate, and onServerDisconnect to make it easier to ensure you have all your bases covered. I think onTerminate is particularly powerful, since “do this thing if the BayeuxClient is dead and not coming back” strikes me as likely to be a very common use case.

Thanks, and let me know what you think.

[sbordet]

I’ve already integrated BayeuxClient 3 with the Reactor library, so doing it for a generic Publisher with version 4 shouldn’t be too dissimilar I hope.

Is this public so I can take a look?

[sbordet]

I’ve also had to define an extension to handle server initiated disconnects, which while not being errors are fatal to the BayeuxClient.

It should have been enough to register a /meta/disconnect listener, I think?

allow us to define handlers like onFatalError, onTerminate

What would be the difference between the two above? I agree that an onTerminate callback would be useful although is definitely not the common case (the common case is that everything works and BayeuxClient can communicate with the server).

We’ll probably do some similar work (ReactiveStream-ing BayeuxClient) for CometD 4, so your input/contributions will be great.

Thanks!