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

[lock] MultiMap lock - Thread is getting stuck on call of lock(key) #9055

Closed
pramodterdale opened this issue Oct 6, 2016 · 7 comments
Closed
Assignees
Milestone

Comments

@pramodterdale
Copy link

@pramodterdale pramodterdale commented Oct 6, 2016

I am using MultiMap implementation for my use case, I need to use MultiMap.lock(key) feature to make sure same key is not getting modified concurrently, i have noticed that the lock(key) method gets called and randomly the thread does not acquire a lock and get stuck forever, I have seen this behavior consistently but on random keys, no specific keys pattern. Most of the keys are unique, i would say 99% of them are unique but 1% of them may be duplicate and need to be handled in multi-threaded env and hence using lock(key) feature. My key column is of type String and using hazelcast and client with version 3.7

String key = getKey();
MultiMap<String, String> mmap = hz.getMultiMap("SampleMap");
mmap.lock(key)  //This line is where thread gets stuck and does not come out
//Do something
mmpa.unlock(key);

Is here any issue with lock feature of MultiMap, any help is very much appreciated..?

@jerrinot jerrinot added this to the 3.8 milestone Oct 19, 2016
@jerrinot
Copy link
Contributor

@jerrinot jerrinot commented Oct 19, 2016

hi @pramodterdale,

is there a chance someone other thread fails to unlock the key? are you always unlocking it a finally block?

@pramodterdale
Copy link
Author

@pramodterdale pramodterdale commented Oct 19, 2016

Yes, in finally block i unlock it, if it fails to unlock in finally block i force unlock it using try/catch block.

finally
{
  try
  {
    mmap.unlock(key);
   }
  catch (Exception e)
  {
    mmap.forceUnlock(key);
  }
}

I read the documentation and it says locks are re-entrant so thread get stuck until it acquires the lock, the way code is written one thread should never hold a lock forever as it is force unlocked. //Do something is simple business logic so thread holding lock does not get stuck in there. I am not able to find out why the second thread is getting stuck on mmpa.lock(key) forever and does not proceed at all.

@mmedenjak
Copy link
Contributor

@mmedenjak mmedenjak commented Jan 3, 2017

@pramodterdale Is this something that you can reproduce easily? Do you know or can you check if some other thread can acquire the lock even when one thread gets stuck on lock? Meaning, can some other thread continue even though one is blocked?

Can you also try using the timed lock version - MultiMap#tryLock(K, long, java.util.concurrent.TimeUnit)? Set the timeout to some value higher than any expected for the business logic duration but short enough that you can observe the thread which failed to acquire the lock. Does the thread unblock after the timeout or does it stay blocked indefinitely?

@mmedenjak mmedenjak self-assigned this Jan 17, 2017
@mmedenjak
Copy link
Contributor

@mmedenjak mmedenjak commented Jan 20, 2017

@pramodterdale Did you have time to try any of the suggestions?

@jerrinot jerrinot modified the milestones: 3.9, 3.8 Jan 24, 2017
@jerrinot
Copy link
Contributor

@jerrinot jerrinot commented Jan 24, 2017

I am moving this ticket into 3.9 as we do not have enough data to act on it as this moment.

@mmedenjak mmedenjak changed the title MultiMap lock - Thread is getting stuck on call of lock(key) [lock] MultiMap lock - Thread is getting stuck on call of lock(key) Jul 11, 2017
@mmedenjak
Copy link
Contributor

@mmedenjak mmedenjak commented Aug 1, 2017

@pramodterdale are you still experiencing this issue? Do you know if there are any membership changes in the cluster?

@mmedenjak
Copy link
Contributor

@mmedenjak mmedenjak commented Aug 21, 2017

@pramodterdale I am closing this issue since we are unable to reproduce it at this moment. If you are still experiencing the issue, you can :

  • try some of the suggestions
  • try upgrading to hazelcast 3.8.4

If the problem persists, please open a new issue.

@mmedenjak mmedenjak closed this Aug 21, 2017
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.

None yet
3 participants
You can’t perform that action at this time.