Skip to content

Conversation

@ihsandemir
Copy link
Collaborator

@ihsandemir ihsandemir commented Jul 12, 2017

After the recent shutdown changes of the client, it is now possible that LifecycleService.shutdown is being called from within the cluster thread and this in turn calls ClusterService.shutdown and this call deletes the cluster thread object. The thread join to the calling thread always succeeds without waiting to avoid deadlocks, and this was one of the changes in recent PRs (#285), hence even though there is a join call in the ClusterService.shutdown, it actually will not wait since the calling thread was the cluster thread itself. It is really dangerous to delete the current running thread object. Solution: Shutdown the thread but do not delete the cluster thread on shutdown.

…etime finish after this ClusterService.shutdown and before hazelcast client destructor exit.
@ihsandemir ihsandemir added this to the 3.8.2 milestone Jul 12, 2017
@ihsandemir ihsandemir self-assigned this Jul 12, 2017
@ihsandemir ihsandemir requested a review from sancar July 12, 2017 11:13
@devOpsHazelcast
Copy link
Contributor

Test PASSed.

@ihsandemir ihsandemir merged commit a3f9495 into hazelcast:master Jul 12, 2017
@ihsandemir ihsandemir deleted the windowsTestIssue221Fix branch July 12, 2017 12:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants