Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Surfacing the last successful pong? #31

Open
thbar opened this issue Oct 11, 2016 · 2 comments
Open

Surfacing the last successful pong? #31

thbar opened this issue Oct 11, 2016 · 2 comments

Comments

@thbar
Copy link

thbar commented Oct 11, 2016

In order to monitor the health of each connection from the application side, it would be great to store the last successful pong timestamp (in redis, for instance), which we could then build alerts on top of depending on our needs.

For some context, I was thinking about how the node-slack-sdk library implements a client-level ping/pong dance and memorizes that timestamp here.

After browsing through relax source code, though, I realize that you are probably relying on the lower-level gorilla websocket connection to handle that ping/pong directly at the websocket level, right?

Even if that's confirmed, it would be indeed great to be able to propagate that information to Rails etc (via Redis), for custom monitoring.

Just some thoughts :-) Keep up the good work!

@thbar
Copy link
Author

thbar commented Oct 11, 2016

I just saw startPingPump so now understand that you are doing something similar to node-slack-sdk. Storing the last timestamp into redis could be useful (but then I do realize there is probably more work to be done, e.g. making sure reconnections attempt are propagated too). Well - just thoughts, again!

@arunthampi
Copy link
Owner

@thbar apologies for getting to this only now. This is a good point and is probably related to #33 -- let me think about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants