[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-10-15 Thread Nicolas Liochon (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Liochon updated HBASE-14521:

   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: (was: 1.3.0)
   Status: Resolved  (was: Patch Available)

Committed to master. I didn't commit to 1.x branch because it's a  behavior 
change...

Thanks for the patch, Yu!.

> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0
>
> Attachments: HBASE-14521.patch, HBASE-14521_v2.patch, 
> HBASE-14521_v3.patch
>
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should unify the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-10-09 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Release Note: 
After this change, hbase.client.reties.number universally means the number of 
retry which is one less than total tries number,  for both non-batch operations 
like get/scan/increment etc. which uses RpcRetryingCallerImpl#callWithRetries 
to submit the call or batch operations like put through AsyncProcess#submit.

Note that previously this property means total tries number for puts, so please 
adjust the setting of its value if necessary. Please also be cautious when 
setting it to zero since retry is necessary for client cache update when region 
move happens.

  was:
After this change, hbase.client.reties.number universally means the number of 
retry which is one less than total tries number,  for both non-batch operations 
like get/scan/increment etc. which uses RpcRetryingCallerImpl#callWithRetries 
to submit the call or batch operations like put through AsyncProcess#submit.

Notice that previously this property means total tries number for puts, so 
please adjust the setting of its value if necessary.


> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14521.patch, HBASE-14521_v2.patch, 
> HBASE-14521_v3.patch
>
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should unify the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-10-08 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Attachment: HBASE-14521_v3.patch

Fix UT failure reported by HadoopQA. The design of 
TestAsyncProcess#testReplicaReplicaSuccessWithParallelFailures means to try 
only once (no retry), and modify the case accordingly with the uniform semantic.

> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14521.patch, HBASE-14521_v2.patch, 
> HBASE-14521_v3.patch
>
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should unify the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-10-08 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Release Note: 
After this change, hbase.client.reties.number universally means the number of 
retry number which is one less than total tries number,  for both non-batch 
operations like get/scan/increment etc. which uses 
RpcRetryingCallerImpl#callWithRetries to submit the call or batch operations 
like put through AsyncProcess#submit.

Notice that previously this property means total tries number for puts, so 
please adjust the setting of its value if necessary.

> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14521.patch, HBASE-14521_v2.patch, 
> HBASE-14521_v3.patch
>
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should unify the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-10-08 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Release Note: 
After this change, hbase.client.reties.number universally means the number of 
retry which is one less than total tries number,  for both non-batch operations 
like get/scan/increment etc. which uses RpcRetryingCallerImpl#callWithRetries 
to submit the call or batch operations like put through AsyncProcess#submit.

Notice that previously this property means total tries number for puts, so 
please adjust the setting of its value if necessary.

  was:
After this change, hbase.client.reties.number universally means the number of 
retry number which is one less than total tries number,  for both non-batch 
operations like get/scan/increment etc. which uses 
RpcRetryingCallerImpl#callWithRetries to submit the call or batch operations 
like put through AsyncProcess#submit.

Notice that previously this property means total tries number for puts, so 
please adjust the setting of its value if necessary.


> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14521.patch, HBASE-14521_v2.patch, 
> HBASE-14521_v3.patch
>
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should unify the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-10-07 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Attachment: HBASE-14521_v2.patch

rebase on latest code

> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-14521.patch, HBASE-14521_v2.patch
>
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should unify the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-10-07 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Fix Version/s: 1.3.0
   2.0.0
   Status: Patch Available  (was: Open)

trigger a HadoopQA run

> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.2, 0.98.14
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14521.patch, HBASE-14521_v2.patch
>
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should unify the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-09-30 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Description: 
>From name of the _hbase.client.retries.number_ property, it should be the 
>number of maximum *retries*, or say if we set the property to 1, there should 
>be 2 attempts in total. However, there're two different semantics when using 
>it in current code base.

For example, in ConnectionImplementation#locateRegionInMeta:
{code}
int localNumRetries = (retry ? numTries : 1);

for (int tries = 0; true; tries++) {
  if (tries >= localNumRetries) {
throw new NoServerForRegionException("Unable to find region for "
+ Bytes.toStringBinary(row) + " in " + tableName +
" after " + numTries + " tries.");
  }
{code}
the retries number is regarded as max times for *tries*

While in RpcRetryingCallerImpl#callWithRetries:
{code}
for (int tries = 0;; tries++) {
  long expectedSleep;
  try {
callable.prepare(tries != 0); // if called with false, check table 
status on ZK
interceptor.intercept(context.prepare(callable, tries));
return callable.call(getRemainingTime(callTimeout));
  } catch (PreemptiveFastFailException e) {
throw e;
  } catch (Throwable t) {
...
if (tries >= retries - 1) {
  throw new RetriesExhaustedException(tries, exceptions);
}
{code}
it's regarded as exactly for *REtry* (try a call first with no condition and 
then check whether to retry or exceeds maximum retry number)

This inconsistency will cause misunderstanding in usage, such as one of our 
customer set the property to zero expecting one single call but finally 
received NoServerForRegionException.

We should unify the semantic of the property, and I suggest to keep the 
original one for retry rather than total tries.

  was:
>From name of the _hbase.client.retries.number_ property, it should be the 
>number of maximum *retries*, or say if we set the property to 1, there should 
>be 2 attempts in total. However, there're two different semantics when using 
>it in current code base.

For example, in ConnectionImplementation#locateRegionInMeta:
{code}
int localNumRetries = (retry ? numTries : 1);

for (int tries = 0; true; tries++) {
  if (tries >= localNumRetries) {
throw new NoServerForRegionException("Unable to find region for "
+ Bytes.toStringBinary(row) + " in " + tableName +
" after " + numTries + " tries.");
  }
{code}
the retries number is regarded as max times for *tries*

While in RpcRetryingCallerImpl#callWithRetries:
{code}
for (int tries = 0;; tries++) {
  long expectedSleep;
  try {
callable.prepare(tries != 0); // if called with false, check table 
status on ZK
interceptor.intercept(context.prepare(callable, tries));
return callable.call(getRemainingTime(callTimeout));
  } catch (PreemptiveFastFailException e) {
throw e;
  } catch (Throwable t) {
...
if (tries >= retries - 1) {
  throw new RetriesExhaustedException(tries, exceptions);
}
{code}
it's regarded as exactly for *REtry* (try a call first with no condition and 
then check whether to retry or exceeds maximum retry number)

This inconsistency will cause misunderstanding in usage, such as one of our 
customer set the property to zero expecting one single call but finally 
received NoServerForRegionException.

We should uniform the semantic of the property, and I suggest to keep the 
original one for retry rather than total tries.


> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, 

[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-09-30 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Summary: Unify the semantic of hbase.client.retries.number  (was: Uniform 
the semantic of hbase.client.retries.number)

> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should uniform the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14521) Unify the semantic of hbase.client.retries.number

2015-09-30 Thread Yu Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li updated HBASE-14521:
--
Attachment: HBASE-14521.patch

Attache the initial patch in sync with [rb|https://reviews.apache.org/r/38886]

>From the change you could also find that we're doing tricks in our UT cases, 
>such as increasing the call number when createAsyncRequestFuture before any 
>real call sent in TestAsyncProcess$MyAsyncProcess

After the change, setting HConstants.HBASE_CLIENT_RETRIES_NUMBER to zero will 
allow user to call only once.

> Unify the semantic of hbase.client.retries.number
> -
>
> Key: HBASE-14521
> URL: https://issues.apache.org/jira/browse/HBASE-14521
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.14, 1.1.2
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-14521.patch
>
>
> From name of the _hbase.client.retries.number_ property, it should be the 
> number of maximum *retries*, or say if we set the property to 1, there should 
> be 2 attempts in total. However, there're two different semantics when using 
> it in current code base.
> For example, in ConnectionImplementation#locateRegionInMeta:
> {code}
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
>   if (tries >= localNumRetries) {
> throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + numTries + " tries.");
>   }
> {code}
> the retries number is regarded as max times for *tries*
> While in RpcRetryingCallerImpl#callWithRetries:
> {code}
> for (int tries = 0;; tries++) {
>   long expectedSleep;
>   try {
> callable.prepare(tries != 0); // if called with false, check table 
> status on ZK
> interceptor.intercept(context.prepare(callable, tries));
> return callable.call(getRemainingTime(callTimeout));
>   } catch (PreemptiveFastFailException e) {
> throw e;
>   } catch (Throwable t) {
> ...
> if (tries >= retries - 1) {
>   throw new RetriesExhaustedException(tries, exceptions);
> }
> {code}
> it's regarded as exactly for *REtry* (try a call first with no condition and 
> then check whether to retry or exceeds maximum retry number)
> This inconsistency will cause misunderstanding in usage, such as one of our 
> customer set the property to zero expecting one single call but finally 
> received NoServerForRegionException.
> We should unify the semantic of the property, and I suggest to keep the 
> original one for retry rather than total tries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)