-
Notifications
You must be signed in to change notification settings - Fork 36
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
Pr fix connect server #703
Pr fix connect server #703
Conversation
667e632
to
a6affcc
Compare
b099c6c
to
9e22e71
Compare
@edwarnicke Could you take a look at this patch that's solve issue #704? Any thoughts are welcome :) |
@edwarnicke , @Bolodya1997 I think this also can be simplified if we will use a refcountmap that allows deleting entry without looking at ref count. What do you think? |
@@ -75,11 +75,16 @@ func (u *clientURLClient) init() error { | |||
u.dialErr = errors.New("cannot dial nil clienturl.ClientURL(ctx)") | |||
return | |||
} | |||
|
|||
ctx, cancel := context.WithTimeout(u.ctx, dialTimeout) |
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 are we introducing a new arbitrary dialTimeout instead of deriving it from the ctx of the request?
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.
It will break discover + roundrobin, because it will wait for the first dial until requests lives and so there won't be any chance to try someone else.
) | ||
|
||
type serializeClient struct { | ||
executor multiExecutor | ||
executor multiexecutor.MultiExecutor |
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.
This feels like a separate PR to introduce multiexecutor into serialize. Could we split it out?
One way or the other, we need to find a way to not be queueing up all Requests/Closes globally in connect. Its fine to queue them up by Connection.ID... but not globally. I think we can get there with a combination of sync.Map and atomics. |
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.
Happy to merge once its rebased to avoid merge conflicts.
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Artem Belov <artem.belov@xored.com>
Signed-off-by: Vladimir Popov <vladimir.popov@xored.com>
Signed-off-by: Vladimir Popov <vladimir.popov@xored.com>
9e22e71
to
b4b875e
Compare
Signed-off-by: Vladimir Popov <vladimir.popov@xored.com>
Signed-off-by: Vladimir Popov <vladimir.popov@xored.com>
Continues #700.
Closes #704.