[ 
https://issues.apache.org/jira/browse/KUDU-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808402#comment-17808402
 ] 

ASF subversion and git services commented on KUDU-3526:
-------------------------------------------------------

Commit 3895f4f796579071615addfa12d2abf75753b9a1 in kudu's branch 
refs/heads/master from 宋家成
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=3895f4f79 ]

KUDU-3526 [java] Scanner should bind with a tserver in java client.

For now, scan requests sent by the java client might fail with scanner
not found error. It is because that scanner does not bind with the
tserver with which it first communicates.

The code in method scanNextRows of java client is still trying to
search for the tserver by the locations and selection policy. So if
the leader is changed and the next scan request is sent to the new
leader, the tserver will respond with the "scanner not found"
exception.

We should bind the scanner to the tserver, similar to how it is done
in the C++ client.

Change-Id: I9cf65f4215e99198dd41b43d14e50c8c23b8a9b2
Reviewed-on: http://gerrit.cloudera.org:8080/20715
Tested-by: Kudu Jenkins
Reviewed-by: Yifan Zhang <chinazhangyi...@163.com>
Reviewed-by: Alexey Serbin <ale...@apache.org>


> [java] Scanner should bound with a tserver in java client.
> ----------------------------------------------------------
>
>                 Key: KUDU-3526
>                 URL: https://issues.apache.org/jira/browse/KUDU-3526
>             Project: Kudu
>          Issue Type: Bug
>            Reporter: Song Jiacheng
>            Priority: Major
>
> We always meet the "scanner not found" exception while using presto + kudu, 
> even if we have set the timeout of scanner very large.
> It turns out the scanner does not bound with the tserver which it first 
> communicates with. 
> Here is the code in scanNextRows of java client:
> {code:java}
> final ServerInfo info = 
> tablet.getReplicaSelectedServerInfo(nextRequest.getReplicaSelection(),
>                                                             location); {code}
> It still trying to find the tserver by the locations and selection policy. So 
> if the leader is changed and the next scan request is sent to the new leader, 
> the tserver will response with the "scanner not found" exception.
> We should make the scanner bound with the tserver, like how it does in c++ 
> client.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to