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

Cancel pending invocations & wait-set entries when client disconnects #13531

Merged
merged 1 commit into from Sep 3, 2018

Conversation

mdogan
Copy link
Contributor

@mdogan mdogan commented Aug 6, 2018

When client wants to execute an operation, a member submits an invocation
on behalf of that client. And when response is received on member-side,
invocation is deregistered and response is forwarded to the client.

If that's a blocking operation, such as lock or reliable-topic message listener,
that operation is parked in a wait-set until it's notified by a notifier operation.
When client is disconnected, entry is wait-set is marked as invalid and removed
from the wait-set eventually.
But invocation on member-side is not notified
and does not receive any response, hence stays in the registry either until timeout
or forever depending on the invocation's target (local or remove)
and/or operation's type (backup-aware or not).

Instead, with this change, when a client is disconnected, wait-set entry will be cancelled
with an exception which then will be propagated to the submitting invocation as a response.
This way, pending invocation will be deregistered.

This is different from the member is removal case. Because members do not submit invocations
on behalf of other members, every member submits and keeps track of its own invocations.

Fixes #13388

When client wants to execute an operation, a member submits an invocation
on behalf of that client. And when response is received on member-side,
invocation is deregistered and response is forwarded to the client.

If that's a blocking operation, such as lock or reliable-topic message listener,
that operation is parked in a wait-set until it's notified by a notifier operation.
When client is disconnected, entry is wait-set is marked as invalid and removed
from the wait-set eventually.
But invocation on member-side is not notified
and does not receive any response, hence stays in the registry either until timeout
or forever depending on the invocation's target (local or remove)
and/or operation's type (backup-aware or not).

Instead, with this change, when a client is disconnected, wait-set entry will be cancelled
with an exception which then will be propagated to the submitting invocation as a response.
This way, pending invocation will be deregistered.

This is different from the member is removal case. Because members do not submit invocations
on behalf of other members, every member submits and keeps track of its own invocations.
@mmedenjak mmedenjak self-requested a review August 29, 2018 06:56
Copy link
Contributor

@mmedenjak mmedenjak left a comment

Choose a reason for hiding this comment

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

Great work, thanks for the fix!

@mmedenjak
Copy link
Contributor

Two approvals, merging.

@mmedenjak mmedenjak merged commit cf1a8ed into hazelcast:master Sep 3, 2018
@mdogan mdogan deleted the client-pending-invocation branch September 10, 2018 08:05
@mmedenjak mmedenjak added the Source: Internal PR or issue was opened by an employee label Apr 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pending invocations not cleaned up on client disconnect
3 participants