Hi Tom, Please correct me if am wrong in understanding the below statement.
The CheckedFuture will produce a derived TransactionCommitFailedException indicating there's no leader or it timed out. You have to wait for the CheckedFuture to be completed one way or another. It may take some number of seconds for it to time out (there are retries to wait for a new shard leader) so it's best not to block on the future. <SATISH> : If we introduce a wait mechanism for the CheckedFuture to be completed, how will this be different than using the CheckedFuture.checkedGet(). In either of these cases the caller (main) thread gets blocked. So are any other ways for the main thread to wait for the CheckedFuture to get completed ? Regards, -Satish From: Tom Pantelis [mailto:[email protected]] Sent: Thursday, February 23, 2017 12:27 AM To: Satish Dutt <[email protected]> Cc: [email protected] Subject: Re: [controller-dev] Shard leader down scenario On Wed, Feb 22, 2017 at 1:36 PM, Satish Dutt <[email protected]<mailto:[email protected]>> wrote: Hi All, We have a 3-node clustered deployment. Code extract : WriteTransaction writeTxn = dataBroker.newWriteOnlyTransaction(); writeTxn.put() CheckedFuture<> checkedFuture = writeTxn.submit() Scenario : 1) Three nodes in the setup N1, N2, N3 2) N3 is the shard leader. 3) All RPC requests from the NBI are sent to N2. 4) First two requests are successful. 5) Before the third request, N3 goes down and there is NO SHARD LEADER 6) Third RPC request is sent to N2 Now will the checkedFuture value be null or error since there is no shard-leader ? Are there any ways to know the shard-leader is down without blocking on the checkedFuture and send an error in the RPC response to the NBI user ? The CheckedFuture will produce a derived TransactionCommitFailedException indicating there's no leader or it timed out. You have to wait for the CheckedFuture to be completed one way or another. It may take some number of seconds for it to time out (there are retries to wait for a new shard leader) so it's best not to block on the future. We are basically hitting this issue while scaling the requests. Regards -Satish _______________________________________________ controller-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________ controller-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/controller-dev
