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

Racy check in TestClientRegistry #10021

Closed
mmedenjak opened this issue Mar 6, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@mmedenjak
Copy link
Contributor

commented Mar 6, 2017

There is a race condition in TestClientRegistry where the tests are calling blockFrom and blockTo before any connection was made (via createSocketConnection) - thus causing a NPE in those block* methods.

The test should wait for the connection to become available before calling block* and unblock* methods (or the methods should somehow not rely on the existence of a connection).

Affects : #9814

@mmedenjak mmedenjak added this to the 3.9 milestone Mar 6, 2017

mmedenjak pushed a commit to mmedenjak/hazelcast that referenced this issue Mar 6, 2017

Matko Medenjak
Fix race conditions in client tests
There are two detected race conditions :
- in TestClientRegistry the methods block or unblock are called before the connection to the member is established. This caused a NPE. The new code allows traffic to be blocked before the connection is established
- in ClientHeartbeatTest when the connection is established after the messages are blocked the test client would not send heartbeats to that client and the test would fail. This is changed so that the test waits for the client to connect to all members before blocking the messages

Fixes : hazelcast#10021

mmedenjak pushed a commit to mmedenjak/hazelcast that referenced this issue Oct 6, 2017

Matko Medenjak
Fix race conditions in client tests
There are two detected race conditions :
- in TestClientRegistry the methods block or unblock are called before the connection to the member is established. This caused a NPE. The new code allows traffic to be blocked before the connection is established
- in ClientHeartbeatTest when the connection is established after the messages are blocked the test client would not send heartbeats to that client and the test would fail. This is changed so that the test waits for the client to connect to all members before blocking the messages

Fixes : hazelcast#10021

(cherry picked from commit af211a1)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.