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

DistributedTask.get() and MultiTask.get() throw OperationTimeoutException #217

Closed
mdogan opened this issue Jul 25, 2012 · 6 comments

Comments

Projects
None yet
2 participants
@mdogan
Copy link
Member

commented Jul 25, 2012

DistributedTask.get() and MultiTask.get() should not throw OperationTimeoutException, should wait indefinitely for result.

@ghost ghost assigned mdogan Jul 25, 2012

@mdogan mdogan closed this in 23da0e1 Jul 25, 2012

@cherron

This comment has been minimized.

Copy link

commented Jul 31, 2012

ConcurrentMapManager#putTransient sets request.timeout to zero, which is failing with OperationTimeoutException in our tests. What should the noResponseTimeout be in this case? Long.MAX_VALUE?

@mdogan

This comment has been minimized.

Copy link
Member Author

commented Aug 1, 2012

Thanks for pointing out. I think noResponseTimeout should remain zero. But we should handle OperationTimeoutException internally not to fail get or contains operations.

I do not see any harm ignoring failure of transient put after a get-load operation.

@cherron

This comment has been minimized.

Copy link

commented Aug 1, 2012

Sorry Mehmet, I misread what was happening. The OperationTimeoutExceptions were actually due to a DistributedTimeoutException returned by the responses.poll call. The log message didn't distinguish the two scenarios clearly. Still investigating why that's happening. Should I create an issue for ignoring failure of transient puts?

@mdogan

This comment has been minimized.

Copy link
Member Author

commented Aug 1, 2012

Are you getting timeout exception while using IMap.putTransient() or while loading data from map store after a get operation?

@cherron

This comment has been minimized.

Copy link

commented Aug 1, 2012

Its happening after a get operation. The gist below includes the stack trace from Hazelcast 2.2 (patched to distinguish OperationTimeoutExceptions thrown from BaseManager). FYI its occurring soon after cluster startup while repartitioning is underway. Let me know if this conversation would be better continued on the mailing list...
https://gist.github.com/addf3b647b020a3ab2a5

@mdogan

This comment has been minimized.

Copy link
Member Author

commented Aug 2, 2012

Oh ok, Hazelcast should handle that OperationTimeoutException internally. I am able to reproduce and fix your case. Fix will be included in 2.2.1.

mdogan added a commit that referenced this issue Aug 2, 2012

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.