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.

Sign up for GitHub

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

Jump to bottom

Consider reducing flow status threshold #138

Closed
michaelklishin opened this issue May 1, 2015 · 3 comments
Closed

Consider reducing flow status threshold #138

michaelklishin opened this issue May 1, 2015 · 3 comments
Assignees
@michaelklishin
Labels
effort-tiny usability
Milestone
3.5.2

Comments

@michaelklishin
Copy link
Member

Currently connections and channels would report itself as "blocked by credit flow" if they were blocked in the last 5 seconds. This means that in some environments, it may seem to an operator like they are in flow control permanently, even though they go in and out of the blocked state many times a second under high load.

We should consider adjusting the threshold to, say, 1 second.
@michaelklishin michaelklishin self-assigned this May 1, 2015
michaelklishin added a commit that referenced this issue May 7, 2015
@michaelklishin
Make credit flow state transition interval 1s instead of 5s
092850a 
Management UI and HTTP API currently report connections and channels
as in flow if they've been in flow for the last 5 seconds. That
can confuse the user with inter-node flow control, making them
believe the flow is permanent (it is not: the actual state
toggles many times a second).

This reduces the interval to 1s, which seems more reasonable and
accurate (in a way).

Fixes #138.
@michaelklishin michaelklishin mentioned this issue May 7, 2015
Merged
@dumbbell
Copy link
Member

dumbbell commented May 7, 2015

One question before I merge the branch. IIRC, the management UI is refreshed every 5": could this change lead to connections/channels to appear as always running, even if they were in flow in the past 5"? I mean, could we end up in the opposite situation: currently it gives the impression connections/channels are always in flow, but with the change, it gives the impression they are never in flow?

@michaelklishin
Copy link
Member Author

That's why we have an issue for adding a ratio. If alarm-driven flow is not in affect, the UI should not emphasize credit flow because it is transient and not displayed accurately with the current approach.

You should still notice resource-driven alarms just as easily with this change.

On 7/5/2015, at 18:02, Jean-Sébastien Pédron [email protected] wrote:

One question before I merge the branch. IIRC, the management UI is refreshed every 5": could this change lead to connections/channels to appear as always running, even if they were in flow in the past 5"? I mean, could we end up in the opposite situation: currently it gives the impression connections/channels are always in flow, but with the change, it gives the impression they are never in flow?

—
Reply to this email directly or view it on GitHub.

@dumbbell
Copy link
Member

Yes, I agree the current UI does not convey the information appropriately.

@dumbbell dumbbell added this to the 3.5.2 milestone May 11, 2015
dcorbacho pushed a commit that referenced this issue Nov 18, 2020
@michaelklishin
Merge pull request #138 from rabbitmq/lrb-confirm-timeout-is-seconds
da95a11 
Document the Timeout parameter to wait_for_confirms
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@michaelklishin michaelklishin

Labels
effort-tiny usability
Projects
None yet
Milestone
3.5.2
Development

No branches or pull requests
2 participants
@michaelklishin @dumbbell