I’ve found that even after the changes in #23, I’m still getting WARN log message logged and output when the WS connection closes.
@tatut my apologies for the torrent of Pull Requests. Please let me know if this is all too burdensome and I can focus on using my own fork of the library most of the time and porting improvements back upstream once they’re more proven.
Deep dive
This time, it’s status code 1006 with reason “Disconnected” — which is
a reasonable case for Jetty WebSocket Client to invoke the on-close
handler that’s set; at this point I think it was just a mistake for me
to try to have this library determine when to log a :warn record vs
an :info record — in other words, to determine what’s “normal” and
what’s “abnormal”. At this point I feel like it’s, generally speaking,
a normal event for these connections to close, even if the closure might
technically seem abnormal to the WebSocket Client library. Since
managing WS connections is only a means to an end for this library,
rather than the main point, I think this library should just use :info
for all WS conn closure events. This should be sufficient for someone
using the library who has a need to debug WS connection issues; all
they’d need to do would be to adjust the level of the Timbre logger
and/or one or more of the Timbre appenders.
This is a follow-up to #23 and #19.
I’ve found that even after the changes in #23, I’m still getting WARN log message logged and output when the WS connection closes.
@tatut my apologies for the torrent of Pull Requests. Please let me know if this is all too burdensome and I can focus on using my own fork of the library most of the time and porting improvements back upstream once they’re more proven.
Deep dive
This time, it’s status code 1006 with reason “Disconnected” — which is a reasonable case for Jetty WebSocket Client to invoke the on-close handler that’s set; at this point I think it was just a mistake for me to try to have this library determine when to log a
:warnrecord vs an:inforecord — in other words, to determine what’s “normal” and what’s “abnormal”. At this point I feel like it’s, generally speaking, a normal event for these connections to close, even if the closure might technically seem abnormal to the WebSocket Client library. Since managing WS connections is only a means to an end for this library, rather than the main point, I think this library should just use:infofor all WS conn closure events. This should be sufficient for someone using the library who has a need to debug WS connection issues; all they’d need to do would be to adjust the level of the Timbre logger and/or one or more of the Timbre appenders.