[JCBC-27] race condition during startup Created: 23/Mar/12  Updated: 04/Mar/13  Resolved: 04/Mar/13

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0, 1.0.1, 1.1dp, 1.1.0
Fix Version/s: 1.1.3
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
During startup, if there is no authentication (and thus no authentication latch) we can reply with errors before we get the configuration back and settled in with the node locator. This should be more reliable.

 Comments   
Comment by Matt Ingenthron [ 23/Mar/12 ]
See http://www.couchbase.com/forums/thread/fast-computer-race-condition-java-client
Comment by Matt Ingenthron [ 29/Aug/12 ]
I think part of the solution on this is to poll the configuration until it transitions from warmup to healthy.
Comment by Matt Ingenthron [ 08/Oct/12 ]
The idea is that there is a section of the code that walks the URIs, finds the bucket, then after finding it sets up the stream for the configuration. When it first finds the bucket, if it's in a "warmup" state, (easy to simulate by restarting a server) it will show that it is and will not have a vbucket map. At that point, we should loop without setting up the stream *or* we should set up the stream and let anything handling reconfigure handle the transition from warmup to warmed up.
Comment by Michael Nitschinger [ 30/Nov/12 ]
http://review.couchbase.com/#/c/22933/1
Comment by Matt Ingenthron [ 03/Dec/12 ]
Still working out the flow here. Based on our current understanding, this can be deferred to 1.1.0 or even post since it's an enhancement for reliable operation in a secondary or tertiary circumstance. Should be release noted though.
Comment by Matt Ingenthron [ 27/Feb/13 ]
Determined that the proposed approach is a good change, but better change is needed. That's tracked under JCBC-255.
Generated at Wed Jul 23 14:13:25 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.