Skip to content
This repository has been archived by the owner on Nov 18, 2020. It is now read-only.

Consider emitting stats for connections unconditionally #70

Closed
michaelklishin opened this issue Mar 8, 2016 · 1 comment
Closed

Consider emitting stats for connections unconditionally #70

michaelklishin opened this issue Mar 8, 2016 · 1 comment
Assignees
@michaelklishin
Labels
effort-tiny usability
Milestone
3.6.2

Comments

@michaelklishin
Copy link
Member

This makes it much easier to reason about connection state/blocking via management UI and/or monitoring tools: we don't sacrifice accuracy.

The downside is that we emit a bit more stats when a lot of connections are blocked. But now that the new parallel event collector is merged, this sounds like a reasonable trade-off.
@michaelklishin michaelklishin self-assigned this Mar 8, 2016
@michaelklishin michaelklishin added this to the 3.6.2 milestone Mar 8, 2016
@michaelklishin michaelklishin mentioned this issue Mar 8, 2016
Closed
michaelklishin added a commit that referenced this issue Mar 8, 2016
@michaelklishin
Emit stats unconditionally
ffc4b89 
of connection (flow control) state.

This makes it much easier to reason about flow control
state when looking at the management UI or monitoring tools
that poll HTTP API.
Now that rabbitmq/rabbitmq-management#41 is merged, there are
few arguments against always emitting stats.

Fixes #70.
This was referenced Mar 8, 2016
Merged
Closed
@hairyhum
Copy link
Contributor

hairyhum commented Mar 8, 2016

Fixed by #71

@hairyhum hairyhum closed this as completed Mar 8, 2016
@michaelklishin michaelklishin mentioned this issue Mar 8, 2016
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@michaelklishin michaelklishin

Labels
effort-tiny usability
Projects
None yet
Milestone
3.6.2
Development

No branches or pull requests
2 participants
@michaelklishin @hairyhum