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.

Sign up for GitHub

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

ReliableTopic listener stops with an unexpected exception #848

Closed
ihsandemir opened this issue Apr 15, 2021 · 1 comment · Fixed by #849
Closed

ReliableTopic listener stops with an unexpected exception #848

ihsandemir opened this issue Apr 15, 2021 · 1 comment · Fixed by #849
Assignees
@ihsandemir
Labels
Source: Community to-jira Use to create a placeholder Jira issue in Jira APIs Project Type: Defect
Milestone
4.1.0

Comments

@ihsandemir
Copy link
Collaborator

Community reported issue: See the slack channel conversation.

User's problem statement:

I got a deadlock recently when subscribing to a reliable topic with the C++ Client v4.0.1 and Hazelcast server v4.1.1.
Basically, the deadlock only occurs if the subscription to a reliable topic is made from a member method of a class. Yeah, pretty strange.
Subscribing to a "normal" topic in the same way does not raise a deadlock. And there is no deadlock if the subscription is made like in your examples.
The event listener simply prints the received string on the standard output. So not a time-consuming operation and no call made to Hazelcast inside the listener.
I manage to create a simple project to reproduce it. The project is attached for you to try to reproduce it.
By experience, the deadlock randomly occurs after less than 30 events are received (so max 30 seconds with the provided publisher).

Reproducer hz_issue.zip is attached for reference.
@ihsandemir ihsandemir added this to the 4.1 milestone Apr 15, 2021
@ihsandemir ihsandemir self-assigned this Apr 15, 2021
ihsandemir added a commit to ihsandemir/hazelcast-cpp-client that referenced this issue Apr 16, 2021
@ihsandemir
Fix for the type of client_config::reliable_topic_config_map_. This…
97b6035 
… map can be modified during client execution and hence can be modified through different user threads. Hence, we have to use a concurrent map.

Actually, only the batch size of the topic config is used, and the name field of the config is not directly used by the implementation and hence, we could have just directly used [this static field](https://github.com/hazelcast/hazelcast-cpp-client/blob/master/hazelcast/include/hazelcast/client/config/reliable_topic_config.h#L31) if no user provided config. But since we provided [the user API](https://github.com/hazelcast/hazelcast-cpp-client/blob/master/hazelcast/include/hazelcast/client/client_config.h#L277) similar to Java and it actually does more than get but also modifies the internal map and it returns a reference to the map entry, i could not really change this actually unneeded API or have this API just return optional if a user provided config exist and not modify the map as expected from a getter. But since, this would mean a change of API, I could not do it and I had to use a concurrent map. That was an unlucky choice during the first implementation.

fixes hazelcast#848
@ihsandemir ihsandemir mentioned this issue Apr 16, 2021
Merged
ihsandemir added a commit to ihsandemir/hazelcast-cpp-client that referenced this issue Apr 16, 2021
@ihsandemir
Fix for the type of client_config::reliable_topic_config_map_. This…
5c84db0 
… map can be modified during client execution and hence can be modified through different user threads. Hence, the solution is to use a different API in the internal implementation `config::reliable_topic_config *find_reliable_topic_config(const std::string &name)` which does not modify the map but uses the default batch size.

fixes hazelcast#848
@ihsandemir
Copy link
Collaborator Author

I also checked the other map usages in the client_config. We have the flake_id_generator_config_map_ and near_cache_config_map_ and there is usage internally where we change the maps once the client is created, hence we do not need any changes on those.

ihsandemir added a commit that referenced this issue Apr 28, 2021
@ihsandemir
client_config::reliable_topic_config_map_ should not be modified co…
6d4a8ff 
…ncurrently. Changed the reliable_topic implementation to utilize the user executor. Cache `reliable_topic` similar to other proxies (#849)

* Fix for the type of `client_config::reliable_topic_config_map_`. This map can be modified during client execution and hence can be modified through different user threads. Hence, the solution is to use a different API in the internal implementation `config::reliable_topic_config *find_reliable_topic_config(const std::string &name)` which does not modify the map but uses the default batch size.

* Changed the reliable_topic implementation to utilize the user executor rather than the custom `ReliableTopicExecutor` implementation. hence, this is more in accordance with the Java client implementation.

* Changed the proxy creation for `reliable_topic` so that it is also being cached similar to other proxies.

fixes #848
@degerhz degerhz added the to-jira Use to create a placeholder Jira issue in Jira APIs Project label Apr 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ihsandemir ihsandemir

Labels
Source: Community to-jira Use to create a placeholder Jira issue in Jira APIs Project Type: Defect
Projects
None yet
Milestone
4.1.0
2 participants
@ihsandemir @degerhz