-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Conversation
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>
c4bdc8b
to
42f45ce
Compare
@@ -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 { |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok that is convincing!
LGTM |
I merged it but doing normal benchmarks it slows things down a bunch so may edit a bit.. |
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