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

[FIXED] Possible delays in delivering messages #895

Merged
merged 1 commit into from Feb 3, 2019

Conversation

kozlovic
Copy link
Member

@kozlovic kozlovic commented Feb 3, 2019

There is a possibility that a partial write results in data
not being sent in a timely fashion to a subscription.

Signed-off-by: Ivan Kozlovic ivan@synadia.com

@coveralls
Copy link

coveralls commented Feb 3, 2019

Coverage Status

Coverage increased (+0.02%) to 91.715% when pulling 42f45ce on fix_possible_writeloop_stall into ae80c4e on master.

There is a possibility that a partial write results in data
not being sent in a timely fashion to a subscription.

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
@@ -917,13 +920,21 @@ func (c *client) flushOutbound() bool {
}
}

// Check that if there is still data to send and writeLoop is in wait,
// we need to signal
if c.out.pb > 0 && c.out.sgw {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just signal, why do we need the bool? I think we may just want to signal on partial?

return true
}

// flushSignal will use server to queue the flush IO operation to a pool of flushers.
// Lock must be held.
func (c *client) flushSignal() {
c.out.sg.Signal()
if c.out.sgw {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we think this is saving us much?

Copy link
Member Author

@kozlovic kozlovic Feb 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did a quick and dirty benchmark of simulating signaling a routine going into a wait, with and without a check with boolean:

Benchmark_SignalWithoutCheck-8   	50000000	        41.6 ns/op
Benchmark____SignalWithCheck-8   	100000000	        19.9 ns/op

But more importantly, even if we don't gain much, why not checking? Signaling while not in wait is just wasted because a signal while not in wait is lost anyway. Since we use mutex to protect wait()/signal(), it makes sense to me to know if we are in wait or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok that is convincing!

@derekcollison
Copy link
Member

LGTM

@derekcollison derekcollison merged commit cfa0685 into master Feb 3, 2019
@derekcollison derekcollison deleted the fix_possible_writeloop_stall branch February 3, 2019 08:13
@derekcollison
Copy link
Member

I merged it but doing normal benchmarks it slows things down a bunch so may edit a bit..

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

Successfully merging this pull request may close these issues.

None yet

3 participants