Re: [controller-dev] Shard leader down scenario

2017-02-23 Thread Tom Pantelis
You can add a callback that gets executed asynchronously when the future
completes, eg

  SettableFuture<RpcResult> rpcResultFuture
= SettableFuture.create();
  Futures.addCallback(checkedFuture, new FutureCallback() {
 @Override
public void onSuccess(final Void notUsed) {

rpcResultFuture.set(RpcResultBuilder.success().build());
}

@Override
public void onFailure(final Throwable t) {
rpcResultFuture.set(RpcResultBuilder. failed()
.withRpcErrors(
((TransactionCommitFailedException)ex).getErrorList() ).build());
}
});

On Thu, Feb 23, 2017 at 2:35 AM, Satish Dutt <sd...@advaoptical.com> wrote:

> 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.*
>
>
>
>  : 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:tompante...@gmail.com]
> *Sent:* Thursday, February 23, 2017 12:27 AM
> *To:* Satish Dutt <sd...@advaoptical.com>
> *Cc:* controller-dev@lists.opendaylight.org
> *Subject:* Re: [controller-dev] Shard leader down scenario
>
>
>
>
>
>
>
> On Wed, Feb 22, 2017 at 1:36 PM, Satish Dutt <sd...@advaoptical.com>
> 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
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Re: [controller-dev] Shard leader down scenario

2017-02-22 Thread Satish Dutt
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.

 : 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:tompante...@gmail.com]
Sent: Thursday, February 23, 2017 12:27 AM
To: Satish Dutt <sd...@advaoptical.com>
Cc: controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Shard leader down scenario



On Wed, Feb 22, 2017 at 1:36 PM, Satish Dutt 
<sd...@advaoptical.com<mailto:sd...@advaoptical.com>> 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
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/controller-dev

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev