Clarify how to handle all fatal errorsSee original GitHub issue
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
onTransportFailureto 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
onServerDisconnectto make it easier to ensure you have all your bases covered. I think
onTerminateis 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.
- Created 5 years ago
- Comments:7 (7 by maintainers)
Top GitHub Comments
Is this public so I can take a look?
It should have been enough to register a
/meta/disconnectlistener, I think?
What would be the difference between the two above? I agree that an
onTerminatecallback would be useful although is definitely not the common case (the common case is that everything works and
BayeuxClientcan communicate with the server).
We’ll probably do some similar work (ReactiveStream-ing
BayeuxClient) for CometD 4, so your input/contributions will be great.