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

Jump to bottom

Client Connection cannot detect idle connection to send ping and server shutdown connection #13576

Closed
asimarslan opened this issue Aug 14, 2018 · 0 comments · Fixed by #13577
Closed

Client Connection cannot detect idle connection to send ping and server shutdown connection #13576

asimarslan opened this issue Aug 14, 2018 · 0 comments · Fixed by #13577
Assignees
@sancar
Labels
Estimation: S Priority: High Source: Internal PR or issue was opened by an employee Team: Client Type: Defect
Milestone
3.10.5

Comments

@asimarslan
Copy link
Contributor

Client connection should detect that a connection is reading but not sending any data to server to detect heartbeat idle case.
Current implementation checks only last read time which is not enough for reading only connections like just simple listener use case.

Possible fix line : HeartbeatManager.java#L94

Test Case:

Two member with a single client that registers a Topic listener on the non-owner member.
Member side publish continuous data to topic and client listener consumes it.
After member heartbeat timeout, member-2 will shutdown client as no ping received.
@asimarslan asimarslan modified the milestones: 3.11, 3.10.5 Aug 14, 2018
@sancar sancar self-assigned this Aug 14, 2018
sancar pushed a commit to sancar/hazelcast that referenced this issue Aug 14, 2018
Server should not close clients when client only listens
9bb70fa 
Client was not sending Ping to server when last read time is
up-to-date. When server constantly pushes events to client,
client does not send any ping to server. And consequently,
server closes client because it does not send any ping.

Client logic has changed so that it send pings if there is no
outgoing packages recently, rarther than looking at incoming
packages.

fixes hazelcast#13576
sancar pushed a commit to sancar/hazelcast that referenced this issue Aug 14, 2018
Server should not close clients when client only listens
fae0871 
Client was not sending Ping to server when last read time is
up-to-date. When server constantly pushes events to client,
client does not send any ping to server. And consequently,
server closes client because it does not send any ping.

Client logic has changed so that it send pings if there is no
outgoing packages recently, rarther than looking at incoming
packages.

fixes hazelcast#13576

(cherry picked from commit 9bb70fa)
This was referenced Aug 14, 2018
Merged
Merged
@asimarslan asimarslan mentioned this issue Aug 14, 2018
Closed
sancar pushed a commit to sancar/hazelcast that referenced this issue Aug 15, 2018
Server should not close clients when client only listens
c8c193f 
Client was not sending Ping to server when last read time is
up-to-date. When server constantly pushes events to client,
client does not send any ping to server. And consequently,
server closes client because it does not send any ping.

Client logic has changed so that it send pings if there is no
outgoing packages recently, rarther than looking at incoming
packages.

fixes hazelcast#13576
sancar pushed a commit to sancar/hazelcast that referenced this issue Aug 15, 2018
Server should not close clients when client only listens
ec5ab10 
Client was not sending Ping to server when last read time is
up-to-date. When server constantly pushes events to client,
client does not send any ping to server. And consequently,
server closes client because it does not send any ping.

Client logic has changed so that it send pings if there is no
outgoing packages recently, rarther than looking at incoming
packages.

fixes hazelcast#13576

(cherry picked from commit 9bb70fa)
This was referenced Aug 28, 2018
Closed
Closed
Closed
Open
@mmedenjak mmedenjak added the Source: Internal PR or issue was opened by an employee label Jan 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sancar sancar

Labels
Estimation: S Priority: High Source: Internal PR or issue was opened by an employee Team: Client Type: Defect
Projects
None yet
Milestone
3.10.5
Development

Successfully merging a pull request may close this issue.

Server should not close clients when client only listens sancar/hazelcast
3 participants
@sancar @asimarslan @mmedenjak