Re: JDBC disconnections over remote networks

[Wesley Chow]

That's totally possible. The ErrorIds are stored on the drillbit machines
right? Our logging is configured incorrectly at the moment so I can't find
the error. Will fix that and report back.

If I limit to 100,000 rows the query consistently works. If I limit to 1M
rows then the query consistently disconnects. If I CTAS on 1M rows then it
works, so it does appear to be an issue only when returning results to the
client. I don't know if there is some value between 100k and 1M for which
it sometimes works and sometimes doesn't. Is that useful to know? I can do
a little binary searching on values if that would help.

Wes


On Mon, Mar 27, 2017 at 4:13 PM, rahul challapalli <
challapallira...@gmail.com> wrote:

> Do you think that the error you are seeing is related to DRILL-4708
>  ? If not kindly provide
> more information about the error (message, stack trace etc). And also does
> the connection error happen consistently after returning X number of
> records or is it random?
>
> - Rahul
>
> On Mon, Mar 27, 2017 at 1:07 PM, Wesley Chow  wrote:
>
> > hi all,
> >
> > I've been noticing that queries that return large numbers of rows (1M+,
> > each row maybe around 500 bytes) via the JDBC connector (and thus
> sqlline)
> > from our office to drillbits in EC2 consistently disconnect with a
> > connection error while streaming the results back. The same query
> initiated
> > from an EC2 machine works fine. Any thoughts on what I should be looking
> > at? When the disconnection occurs, none of my other network connections
> > such as ssh are affected, just the Drill JDBC connector.
> >
> > Thanks,
> > Wes
> >
>

Re: JDBC disconnections over remote networks

[rahul challapalli]

Do you think that the error you are seeing is related to DRILL-4708
 ? If not kindly provide
more information about the error (message, stack trace etc). And also does
the connection error happen consistently after returning X number of
records or is it random?

- Rahul

On Mon, Mar 27, 2017 at 1:07 PM, Wesley Chow  wrote:

> hi all,
>
> I've been noticing that queries that return large numbers of rows (1M+,
> each row maybe around 500 bytes) via the JDBC connector (and thus sqlline)
> from our office to drillbits in EC2 consistently disconnect with a
> connection error while streaming the results back. The same query initiated
> from an EC2 machine works fine. Any thoughts on what I should be looking
> at? When the disconnection occurs, none of my other network connections
> such as ssh are affected, just the Drill JDBC connector.
>
> Thanks,
> Wes
>

JDBC disconnections over remote networks

[Wesley Chow]

hi all,

I've been noticing that queries that return large numbers of rows (1M+,
each row maybe around 500 bytes) via the JDBC connector (and thus sqlline)
from our office to drillbits in EC2 consistently disconnect with a
connection error while streaming the results back. The same query initiated
from an EC2 machine works fine. Any thoughts on what I should be looking
at? When the disconnection occurs, none of my other network connections
such as ssh are affected, just the Drill JDBC connector.

Thanks,
Wes

Re: Wrong property value

[Khurram Faraaz]

We should report a documentation JIRA to track this.


From: Padma Penumarthy 
Sent: Monday, March 27, 2017 7:21:02 PM
To: user@drill.apache.org
Subject: Re: Wrong property value

Yes, you are right. We need to update the documentation with
the correct option name.  Thanks for bringing it up.

Thanks,
Padma


> On Mar 27, 2017, at 1:50 AM, Muhammad Gelbana  wrote:
>
> According to this page
> , Drill can
> implicitly interprets the INT96 timestamp data type in Parquet files after
> setting the *store.parquet.int96_as_timestamp* option to *true*.
>
> I believe the option name should be
> *store.parquet.reader.int96_as_timestamp*
>
> Or did I miss something ?
>
> *-*
> *Muhammad Gelbana*
> http://www.linkedin.com/in/mgelbana

Re: Wrong property value

[Padma Penumarthy]

Yes, you are right. We need to update the documentation with 
the correct option name.  Thanks for bringing it up.

Thanks,
Padma


> On Mar 27, 2017, at 1:50 AM, Muhammad Gelbana  wrote:
> 
> According to this page
> , Drill can
> implicitly interprets the INT96 timestamp data type in Parquet files after
> setting the *store.parquet.int96_as_timestamp* option to *true*.
> 
> I believe the option name should be
> *store.parquet.reader.int96_as_timestamp*
> 
> Or did I miss something ?
> 
> *-*
> *Muhammad Gelbana*
> http://www.linkedin.com/in/mgelbana

Wrong property value

[Muhammad Gelbana]

According to this page
, Drill can
implicitly interprets the INT96 timestamp data type in Parquet files after
setting the *store.parquet.int96_as_timestamp* option to *true*.

I believe the option name should be
*store.parquet.reader.int96_as_timestamp*

Or did I miss something ?

*-*
*Muhammad Gelbana*
http://www.linkedin.com/in/mgelbana