[JCBC-117] mention that OperationFuture.get(tmo) changes state when timeout has been reached Created: 24/Sep/12  Updated: 06/Sep/13

Status: Reopened
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.0.3
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Major
Reporter: Mark Nunberg Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JCBC-114 Command Futures never receive results... Reopened

 Description   
get(tmo) should not change the underlying state of the command to being timed out. It should simply respond with a TimeoutException but allow the command to continue.

Specifically, when the arg-tmo (timeout passed as an argument) expires, the underlying command is marked as timed out. For example, if one waits for 50ms on the command and a response has not been received within that time, the command is now dead ('TIMEDOUT', or similar) and waiting again will not help.

It is understandable that some code might rely on the old behavior, so at the very least, this should be documented in 'BIG RED LETTERS' in the get(tmo) method.

 Comments   
Comment by Matt Ingenthron [ 05/Oct/12 ]
Please explain further.
Comment by Michael Nitschinger [ 16/Oct/12 ]
Hey Mark,

Can you explain in more detail what you want to see changed? When the argument is timed-out what should happen then with it?

Thanks,
Michael
Comment by Matt Ingenthron [ 24/Oct/12 ]
As currently designed, the client uses get() to determine timeout. This is not going to change at the moment. There's no other appropriate place internal to the client to check for this timeout of the operation at the moment.
Comment by Mark Nunberg [ 24/Oct/12 ]
Moving this as a documentation bug
Comment by Matt Ingenthron [ 06/Nov/12 ]
Michael, I'd like you to give this one a shot as your first docs bug, I'll help you with this as needed.
Generated at Wed Oct 01 23:51:19 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.