[
https://issues.apache.org/jira/browse/PHOENIX-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425755#comment-17425755
]
ASF GitHub Bot commented on PHOENIX-6548:
-----------------------------------------
ankitjain64 commented on a change in pull request #1328:
URL: https://github.com/apache/phoenix/pull/1328#discussion_r724465972
##########
File path: phoenix-core/src/main/java/org/apache/phoenix/util/ServerUtil.java
##########
@@ -328,7 +337,16 @@ public void shutdown() {
@Override
public HTableInterface getTable(ImmutableBytesPtr tablename,
ExecutorService pool)
throws IOException {
- return getConnection().getTable(tablename.copyBytesIfNecessary(),
pool);
+ ClusterConnection connection = null;
+ try {
+ connection = getConnection();
+ return connection.getTable(tablename.copyBytesIfNecessary(),
pool);
+ }catch (IllegalArgumentException e) {
Review comment:
@tkhurana I also thought of doing exactly this while making the above
change. But while checking the underlying hbase implementations, when we pass
`pool = null` this
[getDefaultExecutor](https://github.com/apache/hbase/blob/branch-1.4/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java#L213)
is called
[here](https://github.com/apache/hbase/blob/branch-1.4/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java#L320)
to create the ThreadPool, but in the scenario when no pool object is passed
like in our case on [line
320](https://github.com/apache/phoenix/pull/1328/files#diff-28b6df839a384471211d620c7845ea2a40c8ef67e35966a07122bb4f8938086dR320)
the underlying ThreadPool creation is different
[Link](https://github.com/apache/phoenix/pull/1328/files#diff-28b6df839a384471211d620c7845ea2a40c8ef67e35966a07122bb4f8938086dR320)
and
[getBatchPool](https://github.com/apache/hbase/blob/branch-1.4/hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java#L827)
is called. That's why I did merge those two function calls.
Please let me know if I am missing anything and you still think we should
make the above refactor. Thanks
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> Race condition when triggering index rebuilds as regionserver closes
> --------------------------------------------------------------------
>
> Key: PHOENIX-6548
> URL: https://issues.apache.org/jira/browse/PHOENIX-6548
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.14.3, 4.16.1
> Reporter: Geoffrey Jacoby
> Assignee: Ankit Jain
> Priority: Minor
>
> On each regionserver our coprocs keep a cache of HConnections with custom
> settings (such as short timeouts) for talking to other regionservers. They're
> used when coprocs need to make RPCs, such as during index rebuilds.
> When a regionserver is closed, these HConnections are closed as well.
> However, we've seen in our test pipelines a race condition where we may have
> just given out one of the HConnections to a coprocessor, only to have the
> connection closed just before it's used.
> This will produce an IllegalArgumentException from the HBase Table object,
> which (if the index rebuild was caused by a client Scan) will be thrown back
> to the client as a DoNotRetryIOException.
> In this case we want the client exception to be a normal retriable
> IOException, because if they try again after the region comes up again
> somewhere else, the Scan will likely succeed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
