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

Hazelcast (3.8.4) closing listeners #11264

Closed
cryptomorph opened this issue Aug 30, 2017 · 4 comments
Closed

Hazelcast (3.8.4) closing listeners #11264

cryptomorph opened this issue Aug 30, 2017 · 4 comments

Comments

@cryptomorph
Copy link

@cryptomorph cryptomorph commented Aug 30, 2017

Issue

As discussed 2017-08-29 with Al

We are losing notification from a hazelcast node through ITopic listeners (MessageListener). Infrequently (but often enough to be a concern) we lose all notifications for new messages posted to an ITopic that are stored on one node in a cluster. Other nodes in the cluster seem to continue to work normally and the client continues to receive new messages from those nodes. This happens with no exceptions/errors seen at the client side.

This is not an issue with ReliableTopics and associated listeners.

Replication

We can replicate this issue as follows:

  1. Run a cluster of 2 nodes and one client application subscribed to the ITopics.
  2. Post messages (increasing integers) in an ITopic
  3. Repeatedly shut down and restart one node until we see the client logging messages with obvious gaps.
@cryptomorph cryptomorph changed the title Hazelcast closing listeners ... SIS Hazelcast (3.8.4) closing listeners ... SIS Aug 30, 2017
@alparslanavci alparslanavci changed the title Hazelcast (3.8.4) closing listeners ... SIS Hazelcast (3.8.4) closing listeners Aug 30, 2017
@pcortizona
Copy link

@pcortizona pcortizona commented Aug 31, 2017

@sancar
Copy link
Member

@sancar sancar commented Sep 5, 2017

Same problem also reported here
#10101 (comment)
Pasting here as future reference.

@sancar
Copy link
Member

@sancar sancar commented Sep 5, 2017

The issue caused by using hostnames to connect.
For a workaround using ip addresses instead of hostnames will work.

fix is almost ready. It will be applied to 3.9 and backported to 3.8.6
Related issue : #11226

@sancar sancar self-assigned this Sep 5, 2017
@ihsandemir ihsandemir assigned ihsandemir and sancar and unassigned sancar Sep 14, 2017
@ihsandemir ihsandemir reopened this Sep 14, 2017
sancar added a commit to sancar/hazelcast that referenced this issue Sep 14, 2017
Make sure that the provided address string is used in the activeConnectionsMap. This fixes the domain name to ip address conversion problem and duplicate connection initiation problem to the same member one with ip address and one with domain name.

We made the assumption that the user will have to use the same host name or ip in the client config if the member is configured with a public ip address.

fixes hazelcast#11116
fixes hazelcast#11264
backport of hazelcast#11226
@sancar
Copy link
Member

@sancar sancar commented Sep 15, 2017

fixed by #11368

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants
You can’t perform that action at this time.