[
https://issues.apache.org/jira/browse/DRILL-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15894920#comment-15894920
]
Laurent Goujon commented on DRILL-5311:
---------------------------------------
Did some testing using querySubmitter:
before:
{noformat}
$ ./querySubmitter type=server connectStr=local=localhost:31010 api=meta
logLevel=trace
Connector:
name:Apache Drill C++ client
version:1.10.0
Server:
name:
version:
Metadata:
all tables are selectable: 0
catalog separator: .
catalog term: catalog
COLLATE support: 0
correlation names: 3
date time functions: CURDATE, CURTIME, NOW, QUARTER
date time literals support: 65278
GROUP BY support: 0
identifier case: 1
identifier quote string: `
max binary literal length: 0
max catalog name length: 1024
max char literal length: 0
max column name length: 1024
max columns in GROUP BY: 1024
max columns in ORDER BY: 0
max columns in SELECT: 0
max cursor name length: 1024
max logical lob size: 0
max row size: 0
max schema name length: 1024
max statement length: 0
max statements: 0
max table name length: 1024
max tables in SELECT: 0
max user name length: 1024
NULL collation: 1
numeric functions: ABS, EXP, LOG, LOG10, MOD, POWER
OUTER JOIN support: 14
quoted identifier case: 1
SQL keywords:
ABS,ALLOW,ARRAY,ASENSITIVE,ASYMMETRIC,ATOMIC,BIGINT,BINARY,BLOB,BOOLEAN,CALL,CALLED,CARDINALITY,CEIL,CEILING,CLOB,COLLECT,CONDITION,CORR,COVAR_POP,COVAR_SAMP,CUBE,CUME_DIST,CURRENT_CATALOG,CURRENT_DEFAULT_TRANSFORM_GROUP,CURRENT_PATH,CURRENT_ROLE,CURRENT_SCHEMA,CURRENT_TRANSFORM_GROUP_FOR_TYPE,CYCLE,DATABASE,DATABASES,DENSE_RANK,DEREF,DETERMINISTIC,DISALLOW,DYNAMIC,EACH,ELEMENT,EVERY,EXP,EXPLAIN,EXTEND,FILES,FILTER,FIRST_VALUE,FLOOR,FREE,FUNCTION,FUSION,GROUPING,HOLD,IF,IMPORT,INOUT,INTERSECTION,LARGE,LAST_VALUE,LATERAL,LIMIT,LN,LOCALTIME,LOCALTIMESTAMP,MEMBER,MERGE,METADATA,METHOD,MOD,MODIFIES,MULTISET,NCLOB,NEW,NONE,NORMALIZE,OFFSET,OLD,OUT,OVER,OVERLAY,PARAMETER,PARTITION,PERCENTILE_CONT,PERCENTILE_DISC,PERCENT_RANK,POWER,RANGE,RANK,READS,RECURSIVE,REF,REFERENCING,REFRESH,REGR_AVGX,REGR_AVGY,REGR_COUNT,REGR_INTERCEPT,REGR_R2,REGR_SLOPE,REGR_SXX,REGR_SXY,REGR_SYY,RELEASE,REPLACE,RESET,RESULT,RETURN,RETURNS,ROLLUP,ROW,ROW_NUMBER,SAVEPOINT,SCHEMAS,SCOPE,SEARCH,SENSITIVE,SHOW,SIMILAR,SPECIFIC,SPECIFICTYPE,SQLEXCEPTION,SQLWARNING,SQRT,START,STATIC,STDDEV_POP,STDDEV_SAMP,STREAM,SUBMULTISET,SYMMETRIC,SYSTEM,TABLES,TABLESAMPLE,TINYINT,TREAT,TRIGGER,UESCAPE,UNNEST,UPSERT,USE,VARBINARY,VAR_POP,VAR_SAMP,WIDTH_BUCKET,WINDOW,WITHIN,WITHOUT
schema term: schema
search escape string: \
special characters:
string functions:
CONCAT,INSERT,LCASE,LENGTH,LOCATE,LTRIM,RTRIM,SUBSTRING,UCASE
sub query support: 46
system functions:
table term: table
UNION support: 6
BLOB included in max row size: 1
catalog at start: 1
column aliasing supported: 1
LIKE escape clause supported: 1
NULL plus non NULL equals to NULL: 1
read-only: 0
SELECT FOR UPDATE supported: 0
transaction supported: 0
unrelated columns in ORDER BY supported: 1
{noformat}
Note that how the connection didn't fail and it is still possible to query API
(although results are not populated correctly).
after:
{noformat}
$ ./querySubmitter type=server connectStr=local=localhost:31010 api=meta
logLevel=trace
Failed to connect with error: [30015]Handshake Timeout.
(Using:local=localhost:31010)
{noformat}
> C++ connector connect doesn't check handshake result for timeout
> ----------------------------------------------------------------
>
> Key: DRILL-5311
> URL: https://issues.apache.org/jira/browse/DRILL-5311
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - C++
> Reporter: Laurent Goujon
> Assignee: Sudheesh Katkam
> Labels: ready-to-commit
>
> The C++ connector connect methods returns okay as soon as the tcp connection
> is succesfully established between client and server, and the handshake
> message is sent. However it doesn't wait for handshake to have completed.
> The consequence is that if handshake failed, the error is deferred to the
> first query, which might be unexpected by the application.
> I believe that validateHanshake method in drillClientImpl should wait for the
> handshake to complete, as it seems a bit more saner...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
