[jira] [Updated] (DRILL-6918) Querying empty topics fails with "NumberFormatException"
[
https://issues.apache.org/jira/browse/DRILL-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Ravi updated DRILL-6918:
-
Description:
Queries with filter conditions fail with {{NumberFormatException}} when
querying empty topics.
{noformat}
0: jdbc:drill:drillbit=10.10.100.189> select * from `topic2` where Field1 =
'abc';
Error: SYSTEM ERROR: NumberFormatException: abc
Fragment 0:0
Please, refer to logs for more information.
[Error Id: a0718456-c053-4820-9bd8-69c683598344 on qa-node189.qa.lab:31010]
(state=,code=0)
{noformat}
*Logs:*
{noformat}
2018-12-20 22:36:34,576 [23e3760d-7d23-5489-e2fb-6daf383053ee:foreman] INFO
o.a.drill.exec.work.foreman.Foreman - Query text for query with id
23e3760d-7d23-5489-e2fb-6daf383053ee issued by root: select * from `topic2`
where Field1 = 'abc'
2018-12-20 22:36:35,134 [23e3760d-7d23-5489-e2fb-6daf383053ee:foreman] INFO
o.a.d.e.s.k.KafkaPushDownFilterIntoScan - Partitions ScanSpec before pushdown:
[KafkaPartitionScanSpec [topicName=topic2, partitionId=2, startOffset=0,
endOffset=0], KafkaPartitionScanSpec [topicName=topic2, partitionId=1,
startOffset=0, endOffset=0], KafkaPartitionScanSpec [topicName=topic2,
partitionId=0, startOffset=0, endOffset=0]]
2018-12-20 22:36:35,170 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.s.k.KafkaScanBatchCreator - Number of record readers initialized : 3
2018-12-20 22:36:35,171 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.w.fragment.FragmentExecutor - 23e3760d-7d23-5489-e2fb-6daf383053ee:0:0:
State change requested AWAITING_ALLOCATION --> RUNNING
2018-12-20 22:36:35,172 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.w.f.FragmentStatusReporter - 23e3760d-7d23-5489-e2fb-6daf383053ee:0:0:
State to report: RUNNING
2018-12-20 22:36:35,173 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.s.k.d.MessageReaderFactory - Initialized Message Reader :
JsonMessageReader[jsonReader=null]
2018-12-20 22:36:35,177 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.store.kafka.MessageIterator - Start offset of topic2:2 is - 0
2018-12-20 22:36:35,177 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.s.kafka.KafkaRecordReader - Last offset processed for topic2:2 is - 0
2018-12-20 22:36:35,177 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.s.kafka.KafkaRecordReader - Total time to fetch messages from topic2:2
is - 0 milliseconds
2018-12-20 22:36:35,178 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] WARN
o.a.d.e.e.ExpressionTreeMaterializer - Unable to find value vector of path
`Field1`, returning null instance.
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.w.fragment.FragmentExecutor - 23e3760d-7d23-5489-e2fb-6daf383053ee:0:0:
State change requested RUNNING --> FAILED
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.physical.impl.BaseRootExec - Batch dump started: dumping last 2 failed
batches
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.p.i.s.RemovingRecordBatch -
RemovingRecordBatch[container=org.apache.drill.exec.record.VectorContainer@3ce6a91e[recordCount
= 0, schemaChanged = true, schema = null, wrappers = [], ...], state=FIRST,
copier=null]
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.p.i.filter.FilterRecordBatch -
FilterRecordBatch[container=org.apache.drill.exec.record.VectorContainer@2057ff66[recordCount
= 0, schemaChanged = true, schema = null, wrappers =
[org.apache.drill.exec.vector.NullableIntVector@32edcdf2[field = [`T4¦¦**`
(INT:OPTIONAL)], ...],
org.apache.drill.exec.vector.NullableIntVector@3a5bf582[field = [`Field1`
(INT:OPTIONAL)], ...]], ...], selectionVector2=[SV2: recs=0 - ], filter=null,
popConfig=org.apache.drill.exec.physical.config.Filter@1d69df75]
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.physical.impl.BaseRootExec - Batch dump completed.
2018-12-20 22:36:35,192 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.w.fragment.FragmentExecutor - 23e3760d-7d23-5489-e2fb-6daf383053ee:0:0:
State change requested FAILED --> FINISHED
2018-12-20 22:36:35,194 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.w.fragment.FragmentExecutor - SYSTEM ERROR: NumberFormatException: abc
Fragment 0:0
Please, refer to logs for more information.
[Error Id: a0718456-c053-4820-9bd8-69c683598344 on qa-node189.qa.lab:31010]
org.apache.drill.common.exceptions.UserException: SYSTEM ERROR:
NumberFormatException: abc
Fragment 0:0
Please, refer to logs for more information.
[Error Id: a0718456-c053-4820-9bd8-69c683598344 on qa-node189.qa.lab:31010]
at
org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:633)
~[drill-common-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
[jira] [Created] (DRILL-6918) Querying empty topics fails with "NumberFormatException"
Abhishek Ravi created DRILL-6918:
Summary: Querying empty topics fails with "NumberFormatException"
Key: DRILL-6918
URL: https://issues.apache.org/jira/browse/DRILL-6918
Project: Apache Drill
Issue Type: Bug
Components: Storage - Kafka
Affects Versions: 1.14.0
Reporter: Abhishek Ravi
Assignee: Abhishek Ravi
Fix For: 1.16.0
Queries with filter conditions fail with {{NumberFormatException}} when
querying empty topics.
{noformat}
2018-12-20 22:36:34,576 [23e3760d-7d23-5489-e2fb-6daf383053ee:foreman] INFO
o.a.drill.exec.work.foreman.Foreman - Query text for query with id
23e3760d-7d23-5489-e2fb-6daf383053ee issued by root: select * from `topic2`
where Field1 = 'abc'
2018-12-20 22:36:35,134 [23e3760d-7d23-5489-e2fb-6daf383053ee:foreman] INFO
o.a.d.e.s.k.KafkaPushDownFilterIntoScan - Partitions ScanSpec before pushdown:
[KafkaPartitionScanSpec [topicName=topic2, partitionId=2, startOffset=0,
endOffset=0], KafkaPartitionScanSpec [topicName=topic2, partitionId=1,
startOffset=0, endOffset=0], KafkaPartitionScanSpec [topicName=topic2,
partitionId=0, startOffset=0, endOffset=0]]
2018-12-20 22:36:35,170 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.s.k.KafkaScanBatchCreator - Number of record readers initialized : 3
2018-12-20 22:36:35,171 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.w.fragment.FragmentExecutor - 23e3760d-7d23-5489-e2fb-6daf383053ee:0:0:
State change requested AWAITING_ALLOCATION --> RUNNING
2018-12-20 22:36:35,172 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.w.f.FragmentStatusReporter - 23e3760d-7d23-5489-e2fb-6daf383053ee:0:0:
State to report: RUNNING
2018-12-20 22:36:35,173 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.s.k.d.MessageReaderFactory - Initialized Message Reader :
JsonMessageReader[jsonReader=null]
2018-12-20 22:36:35,177 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.store.kafka.MessageIterator - Start offset of topic2:2 is - 0
2018-12-20 22:36:35,177 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.s.kafka.KafkaRecordReader - Last offset processed for topic2:2 is - 0
2018-12-20 22:36:35,177 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.s.kafka.KafkaRecordReader - Total time to fetch messages from topic2:2
is - 0 milliseconds
2018-12-20 22:36:35,178 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] WARN
o.a.d.e.e.ExpressionTreeMaterializer - Unable to find value vector of path
`Field1`, returning null instance.
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.w.fragment.FragmentExecutor - 23e3760d-7d23-5489-e2fb-6daf383053ee:0:0:
State change requested RUNNING --> FAILED
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.physical.impl.BaseRootExec - Batch dump started: dumping last 2 failed
batches
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.p.i.s.RemovingRecordBatch -
RemovingRecordBatch[container=org.apache.drill.exec.record.VectorContainer@3ce6a91e[recordCount
= 0, schemaChanged = true, schema = null, wrappers = [], ...], state=FIRST,
copier=null]
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.p.i.filter.FilterRecordBatch -
FilterRecordBatch[container=org.apache.drill.exec.record.VectorContainer@2057ff66[recordCount
= 0, schemaChanged = true, schema = null, wrappers =
[org.apache.drill.exec.vector.NullableIntVector@32edcdf2[field = [`T4¦¦**`
(INT:OPTIONAL)], ...],
org.apache.drill.exec.vector.NullableIntVector@3a5bf582[field = [`Field1`
(INT:OPTIONAL)], ...]], ...], selectionVector2=[SV2: recs=0 - ], filter=null,
popConfig=org.apache.drill.exec.physical.config.Filter@1d69df75]
2018-12-20 22:36:35,191 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.physical.impl.BaseRootExec - Batch dump completed.
2018-12-20 22:36:35,192 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] INFO
o.a.d.e.w.fragment.FragmentExecutor - 23e3760d-7d23-5489-e2fb-6daf383053ee:0:0:
State change requested FAILED --> FINISHED
2018-12-20 22:36:35,194 [23e3760d-7d23-5489-e2fb-6daf383053ee:frag:0:0] ERROR
o.a.d.e.w.fragment.FragmentExecutor - SYSTEM ERROR: NumberFormatException: abc
Fragment 0:0
Please, refer to logs for more information.
[Error Id: a0718456-c053-4820-9bd8-69c683598344 on qa-node189.qa.lab:31010]
org.apache.drill.common.exceptions.UserException: SYSTEM ERROR:
NumberFormatException: abc
Fragment 0:0
Please, refer to logs for more information.
[Error Id: a0718456-c053-4820-9bd8-69c683598344 on qa-node189.qa.lab:31010]
at
org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:633)
~[drill-common-1.15.0-SNAPSHOT.jar:1.15.0-SNAPSHOT]
at
[jira] [Assigned] (DRILL-5360) Timestamp type documented as UTC, implemented as local time
[
https://issues.apache.org/jira/browse/DRILL-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pritesh Maker reassigned DRILL-5360:
Assignee: Bohdan Kazydub
> Timestamp type documented as UTC, implemented as local time
> ---
>
> Key: DRILL-5360
> URL: https://issues.apache.org/jira/browse/DRILL-5360
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Paul Rogers
>Assignee: Bohdan Kazydub
>Priority: Critical
> Fix For: 1.16.0
>
>
> The Drill documentation implies that the {{Timestamp}} type is in UTC:
> bq. JDBC timestamp in year, month, date hour, minute, second, and optional
> milliseconds format: -MM-dd HH:mm:ss.SSS. ... TIMESTAMP literals: Drill
> stores values in Coordinated Universal Time (UTC). Drill supports time
> functions in the range 1971 to 2037. ... Drill does not support TIMESTAMP
> with time zone.
> The above is ambiguous. The first part talks about JDBC timestamps. From the
> JDK Javadoc:
> bq. Timestamp: A thin wrapper around java.util.Date. ... Date class is
> intended to reflect coordinated universal time (UTC)...
> So, a JDBC timestamp is intended to represent time in UTC. (The "indented to
> reflect" statement leaves open the possibility of misusing {{Date}} to
> represent times in other time zones. This was common practice in early Java
> development and was the reason for the eventual development of the Joda, then
> Java 8 date/time classes.)
> The Drill documentation implies that timestamp *literals* are in UTC, but a
> careful read of the documentation does allow an interpretation that the
> internal representation can be other than UTC. If this is true, then we would
> also rely on a liberal reading of the Java `Timestamp` class to also not be
> UTC. (Or, we rely on the Drill JDBC driver to convert from the (unknown)
> server time zone to a UTC value returned by the Drill JDBC client.)
> Still, a superficial reading (and common practice) would suggest that a Drill
> Timestamp should be in UTC.
> However, a test on a Mac, with an embedded Drillbit (run in the Pacific time
> zone, with Daylight Savings Time in effect) shows that the Timestamp binary
> value is actual local time:
> {code}
> long before = System.currentTimeMillis();
> long value = getDateValue(client, "SELECT NOW() FROM (VALUES(1))" );
> double hrsDiff = (value - before) / (1000.00 * 60 * 60);
> System.out.println("Hours: " + hrsDiff);
> {code}
> The above gets the actual UTC time from Java. Then, it runs a query that gets
> Drill's idea of the current time using the {{NOW()}} function. (The
> {{getDateValue}} function uses the new test framework to access the actual
> {{long}} value from the returned value vector.) Finally, we compute the
> difference between the two times, converted to hours. Output:
> {code}
> Hours: -6.975
> {code}
> As it turns out, this is the difference between UTC and PDT. So, the time is
> in local time, not UTC.
> Since the documentation and implementation are both ambiguous, it is hard to
> know the intent of the Drill Timestamp. Clearly, common practice is to use
> UTC. But, there is wiggle-room.
> If the Timestamp value is supposed to be local time, then Drill should
> provide a function to return the server's time zone offset (in ms) from UTC
> so that the client can to the needed local-to-UTC conversion to get a true
> timestamp.
> On the other hand, if the Timestamp is supposed to be UTC (per common
> practice), then {{NOW()}} should not report local time, it should return UTC.
> Further, if {{NOW()}} returns local time, but Timestamp literals are UTC,
> then it is hard to see how any query can be rationally written if one
> timestamp value is local, but a literal is UTC.
> So, job #1 is to define the Timestamp semantics. Then, use that to figure out
> where the bug lies to make implementation consistent with documentation (or
> visa-versa.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-5360) Timestamp type documented as UTC, implemented as local time
[
https://issues.apache.org/jira/browse/DRILL-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726443#comment-16726443
]
Pritesh Maker commented on DRILL-5360:
--
[~KazydubB] can you please analyze this and determine what it would take to
make timezone consistent?
> Timestamp type documented as UTC, implemented as local time
> ---
>
> Key: DRILL-5360
> URL: https://issues.apache.org/jira/browse/DRILL-5360
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Paul Rogers
>Assignee: Bohdan Kazydub
>Priority: Critical
> Fix For: 1.16.0
>
>
> The Drill documentation implies that the {{Timestamp}} type is in UTC:
> bq. JDBC timestamp in year, month, date hour, minute, second, and optional
> milliseconds format: -MM-dd HH:mm:ss.SSS. ... TIMESTAMP literals: Drill
> stores values in Coordinated Universal Time (UTC). Drill supports time
> functions in the range 1971 to 2037. ... Drill does not support TIMESTAMP
> with time zone.
> The above is ambiguous. The first part talks about JDBC timestamps. From the
> JDK Javadoc:
> bq. Timestamp: A thin wrapper around java.util.Date. ... Date class is
> intended to reflect coordinated universal time (UTC)...
> So, a JDBC timestamp is intended to represent time in UTC. (The "indented to
> reflect" statement leaves open the possibility of misusing {{Date}} to
> represent times in other time zones. This was common practice in early Java
> development and was the reason for the eventual development of the Joda, then
> Java 8 date/time classes.)
> The Drill documentation implies that timestamp *literals* are in UTC, but a
> careful read of the documentation does allow an interpretation that the
> internal representation can be other than UTC. If this is true, then we would
> also rely on a liberal reading of the Java `Timestamp` class to also not be
> UTC. (Or, we rely on the Drill JDBC driver to convert from the (unknown)
> server time zone to a UTC value returned by the Drill JDBC client.)
> Still, a superficial reading (and common practice) would suggest that a Drill
> Timestamp should be in UTC.
> However, a test on a Mac, with an embedded Drillbit (run in the Pacific time
> zone, with Daylight Savings Time in effect) shows that the Timestamp binary
> value is actual local time:
> {code}
> long before = System.currentTimeMillis();
> long value = getDateValue(client, "SELECT NOW() FROM (VALUES(1))" );
> double hrsDiff = (value - before) / (1000.00 * 60 * 60);
> System.out.println("Hours: " + hrsDiff);
> {code}
> The above gets the actual UTC time from Java. Then, it runs a query that gets
> Drill's idea of the current time using the {{NOW()}} function. (The
> {{getDateValue}} function uses the new test framework to access the actual
> {{long}} value from the returned value vector.) Finally, we compute the
> difference between the two times, converted to hours. Output:
> {code}
> Hours: -6.975
> {code}
> As it turns out, this is the difference between UTC and PDT. So, the time is
> in local time, not UTC.
> Since the documentation and implementation are both ambiguous, it is hard to
> know the intent of the Drill Timestamp. Clearly, common practice is to use
> UTC. But, there is wiggle-room.
> If the Timestamp value is supposed to be local time, then Drill should
> provide a function to return the server's time zone offset (in ms) from UTC
> so that the client can to the needed local-to-UTC conversion to get a true
> timestamp.
> On the other hand, if the Timestamp is supposed to be UTC (per common
> practice), then {{NOW()}} should not report local time, it should return UTC.
> Further, if {{NOW()}} returns local time, but Timestamp literals are UTC,
> then it is hard to see how any query can be rationally written if one
> timestamp value is local, but a literal is UTC.
> So, job #1 is to define the Timestamp semantics. Then, use that to figure out
> where the bug lies to make implementation consistent with documentation (or
> visa-versa.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-5360) Timestamp type documented as UTC, implemented as local time
[
https://issues.apache.org/jira/browse/DRILL-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pritesh Maker updated DRILL-5360:
-
Fix Version/s: (was: 2.0.0)
1.16.0
> Timestamp type documented as UTC, implemented as local time
> ---
>
> Key: DRILL-5360
> URL: https://issues.apache.org/jira/browse/DRILL-5360
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Paul Rogers
>Assignee: Bohdan Kazydub
>Priority: Critical
> Fix For: 1.16.0
>
>
> The Drill documentation implies that the {{Timestamp}} type is in UTC:
> bq. JDBC timestamp in year, month, date hour, minute, second, and optional
> milliseconds format: -MM-dd HH:mm:ss.SSS. ... TIMESTAMP literals: Drill
> stores values in Coordinated Universal Time (UTC). Drill supports time
> functions in the range 1971 to 2037. ... Drill does not support TIMESTAMP
> with time zone.
> The above is ambiguous. The first part talks about JDBC timestamps. From the
> JDK Javadoc:
> bq. Timestamp: A thin wrapper around java.util.Date. ... Date class is
> intended to reflect coordinated universal time (UTC)...
> So, a JDBC timestamp is intended to represent time in UTC. (The "indented to
> reflect" statement leaves open the possibility of misusing {{Date}} to
> represent times in other time zones. This was common practice in early Java
> development and was the reason for the eventual development of the Joda, then
> Java 8 date/time classes.)
> The Drill documentation implies that timestamp *literals* are in UTC, but a
> careful read of the documentation does allow an interpretation that the
> internal representation can be other than UTC. If this is true, then we would
> also rely on a liberal reading of the Java `Timestamp` class to also not be
> UTC. (Or, we rely on the Drill JDBC driver to convert from the (unknown)
> server time zone to a UTC value returned by the Drill JDBC client.)
> Still, a superficial reading (and common practice) would suggest that a Drill
> Timestamp should be in UTC.
> However, a test on a Mac, with an embedded Drillbit (run in the Pacific time
> zone, with Daylight Savings Time in effect) shows that the Timestamp binary
> value is actual local time:
> {code}
> long before = System.currentTimeMillis();
> long value = getDateValue(client, "SELECT NOW() FROM (VALUES(1))" );
> double hrsDiff = (value - before) / (1000.00 * 60 * 60);
> System.out.println("Hours: " + hrsDiff);
> {code}
> The above gets the actual UTC time from Java. Then, it runs a query that gets
> Drill's idea of the current time using the {{NOW()}} function. (The
> {{getDateValue}} function uses the new test framework to access the actual
> {{long}} value from the returned value vector.) Finally, we compute the
> difference between the two times, converted to hours. Output:
> {code}
> Hours: -6.975
> {code}
> As it turns out, this is the difference between UTC and PDT. So, the time is
> in local time, not UTC.
> Since the documentation and implementation are both ambiguous, it is hard to
> know the intent of the Drill Timestamp. Clearly, common practice is to use
> UTC. But, there is wiggle-room.
> If the Timestamp value is supposed to be local time, then Drill should
> provide a function to return the server's time zone offset (in ms) from UTC
> so that the client can to the needed local-to-UTC conversion to get a true
> timestamp.
> On the other hand, if the Timestamp is supposed to be UTC (per common
> practice), then {{NOW()}} should not report local time, it should return UTC.
> Further, if {{NOW()}} returns local time, but Timestamp literals are UTC,
> then it is hard to see how any query can be rationally written if one
> timestamp value is local, but a literal is UTC.
> So, job #1 is to define the Timestamp semantics. Then, use that to figure out
> where the bug lies to make implementation consistent with documentation (or
> visa-versa.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DRILL-3853) Get off Sqlline fork
[ https://issues.apache.org/jira/browse/DRILL-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726434#comment-16726434 ] Bridget Bevens edited comment on DRILL-3853 at 12/21/18 4:31 AM: - Hi [~arina], I built and installed Drill from source a couple of days ago, and when I ran !set, this returned: version sqlline version 1.6.0 Is SQLLine 1.5 or 1.6 the correct version for Drill 1.15? Also, I plan to add a note about the SQLLine upgrade in the release notes. I also plan to add the following write-up to the docs: *Customizing SQLLine in the drill-sqlline-override.conf File* Starting in Drill 1.15, SQLLine (the Drill shell) is upgraded to version 1.6. You can customize SQLLine through the Drill configuration file, drill-sqlline-override.conf, located in the /conf directory. You can customize quotes of the day; the quotes you see at the command prompt when starting Drill, such as “Just Drill it,” and you can override the SQLLine default properties. The SQLLine default properties are those that print when you run !set from the Drill shell. Drill reads the drill-sqlline-override.conf file and applies the customizes during start-up. You must restart Drill for the changes to take effect. The file remains in the directory and Drill applies the customizes at each restart. *Note:* The SQLLine configuration in the /conf directory is named drill-sqlline-override-example.conf. Use the examples and information provided in the file for guidance. Create a new file in the directory named drill-sqlline-override.conf with your customizations. Please let me know if I need to change anything. Thank you! Bridget was (Author: bbevens): Hi [~arina], I built and installed Drill from source a couple of days ago, and when I ran !set, this returned: version sqlline version 1.6.0 Is SQLLine 1.5 or 1.6 the correct version for Drill 1.15? Also, I plan to add a note about the SQLLine upgrade in the release notes. I also plan to add the following write-up to the docs: *Customizing SQLLine in the drill-sqlline-override.conf File* _Starting in Drill 1.15, SQLLine (the Drill shell) is upgraded to version 1.6. You can customize SQLLine through the Drill configuration file, drill-sqlline-override.conf, located in the /conf directory. You can customize quotes of the day; the quotes you see at the command prompt when starting Drill, such as “Just Drill it,” and you can override the SQLLine default properties. The SQLLine default properties are those that print when you run !set from the Drill shell. Drill reads the drill-sqlline-override.conf file and applies the customizes during start-up. You must restart Drill for the changes to take effect. The file remains in the directory and Drill applies the customizes at each restart. *Note:* The SQLLine configuration in the /conf directory is named drill-sqlline-override-example.conf. Use the examples and information provided in the file for guidance. Create a new file in the directory named drill-sqlline-override.conf with your customizations. _ Please let me know if I need to change anything. Thank you! Bridget > Get off Sqlline fork > > > Key: DRILL-3853 > URL: https://issues.apache.org/jira/browse/DRILL-3853 > Project: Apache Drill > Issue Type: Improvement >Reporter: Parth Chandra >Assignee: Arina Ielchiieva >Priority: Major > Labels: doc-impacting, ready-to-commit > Fix For: 1.15.0 > > > Drill has it's own forked version of sqlline that includes customizations for > displaying the drill version, drill QOTD, removing names of unsupported > commands and removing JDBC drivers not shipped with Drill. > To get off the fork, we need to parameterize these features in sqlline and > have them driven from a properties file. The changes should be merged back > into sqlline and Drill packaging should then provide a properties file to > customize the stock sqlline distribution. > *For documentation* > SqlLine was upgraded to 1.5.0. > Added ability to customize SqlLine via drill-sqlline-override.conf file which > should be present in the classpath. > Example if placed in conf folder - drill-sqlline-override-example.conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-3853) Get off Sqlline fork
[ https://issues.apache.org/jira/browse/DRILL-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726434#comment-16726434 ] Bridget Bevens commented on DRILL-3853: --- Hi [~arina], I built and installed Drill from source a couple of days ago, and when I ran !set, this returned: version sqlline version 1.6.0 Is SQLLine 1.5 or 1.6 the correct version for Drill 1.15? Also, I plan to add a note about the SQLLine upgrade in the release notes. I also plan to add the following write-up to the docs: *Customizing SQLLine in the drill-sqlline-override.conf File* _Starting in Drill 1.15, SQLLine (the Drill shell) is upgraded to version 1.6. You can customize SQLLine through the Drill configuration file, drill-sqlline-override.conf, located in the /conf directory. You can customize quotes of the day; the quotes you see at the command prompt when starting Drill, such as “Just Drill it,” and you can override the SQLLine default properties. The SQLLine default properties are those that print when you run !set from the Drill shell. Drill reads the drill-sqlline-override.conf file and applies the customizes during start-up. You must restart Drill for the changes to take effect. The file remains in the directory and Drill applies the customizes at each restart. *Note:* The SQLLine configuration in the /conf directory is named drill-sqlline-override-example.conf. Use the examples and information provided in the file for guidance. Create a new file in the directory named drill-sqlline-override.conf with your customizations. _ Please let me know if I need to change anything. Thank you! Bridget > Get off Sqlline fork > > > Key: DRILL-3853 > URL: https://issues.apache.org/jira/browse/DRILL-3853 > Project: Apache Drill > Issue Type: Improvement >Reporter: Parth Chandra >Assignee: Arina Ielchiieva >Priority: Major > Labels: doc-impacting, ready-to-commit > Fix For: 1.15.0 > > > Drill has it's own forked version of sqlline that includes customizations for > displaying the drill version, drill QOTD, removing names of unsupported > commands and removing JDBC drivers not shipped with Drill. > To get off the fork, we need to parameterize these features in sqlline and > have them driven from a properties file. The changes should be merged back > into sqlline and Drill packaging should then provide a properties file to > customize the stock sqlline distribution. > *For documentation* > SqlLine was upgraded to 1.5.0. > Added ability to customize SqlLine via drill-sqlline-override.conf file which > should be present in the classpath. > Example if placed in conf folder - drill-sqlline-override-example.conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (DRILL-3853) Get off Sqlline fork
[ https://issues.apache.org/jira/browse/DRILL-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726434#comment-16726434 ] Bridget Bevens edited comment on DRILL-3853 at 12/21/18 4:33 AM: - Hi [~arina], I built and installed Drill from source a couple of days ago, and when I ran !set, this returned: version sqlline version 1.6.0 Is SQLLine 1.5 or 1.6 the correct version for Drill 1.15? Also, I plan to add a note about the SQLLine upgrade in the release notes. I also plan to add the following write-up to the docs: *Customizing SQLLine in the drill-sqlline-override.conf File* Starting in Drill 1.15, SQLLine (the Drill shell) is upgraded to version 1.6. You can customize SQLLine through the Drill configuration file, drill-sqlline-override.conf, located in the /conf directory. You can customize quotes of the day; the quotes you see at the command prompt when starting Drill, such as “Just Drill it,” and you can override the SQLLine default properties. The SQLLine default properties are those that print when you run !set from the Drill shell. Drill reads the drill-sqlline-override.conf file and applies the customizes during start-up. You must restart Drill for the changes to take effect. The file remains in the directory and Drill applies the customizes at each restart. *Note:* The SQLLine configuration file in the /conf directory is named drill-sqlline-override-example.conf. Use this file and the information provided as guidance for the . drill-sqlline-override.conf file you create and store in the directory with your customizations. Please let me know if I need to change anything. Thank you! Bridget was (Author: bbevens): Hi [~arina], I built and installed Drill from source a couple of days ago, and when I ran !set, this returned: version sqlline version 1.6.0 Is SQLLine 1.5 or 1.6 the correct version for Drill 1.15? Also, I plan to add a note about the SQLLine upgrade in the release notes. I also plan to add the following write-up to the docs: *Customizing SQLLine in the drill-sqlline-override.conf File* Starting in Drill 1.15, SQLLine (the Drill shell) is upgraded to version 1.6. You can customize SQLLine through the Drill configuration file, drill-sqlline-override.conf, located in the /conf directory. You can customize quotes of the day; the quotes you see at the command prompt when starting Drill, such as “Just Drill it,” and you can override the SQLLine default properties. The SQLLine default properties are those that print when you run !set from the Drill shell. Drill reads the drill-sqlline-override.conf file and applies the customizes during start-up. You must restart Drill for the changes to take effect. The file remains in the directory and Drill applies the customizes at each restart. *Note:* The SQLLine configuration in the /conf directory is named drill-sqlline-override-example.conf. Use the examples and information provided in the file for guidance. Create a new file in the directory named drill-sqlline-override.conf with your customizations. Please let me know if I need to change anything. Thank you! Bridget > Get off Sqlline fork > > > Key: DRILL-3853 > URL: https://issues.apache.org/jira/browse/DRILL-3853 > Project: Apache Drill > Issue Type: Improvement >Reporter: Parth Chandra >Assignee: Arina Ielchiieva >Priority: Major > Labels: doc-impacting, ready-to-commit > Fix For: 1.15.0 > > > Drill has it's own forked version of sqlline that includes customizations for > displaying the drill version, drill QOTD, removing names of unsupported > commands and removing JDBC drivers not shipped with Drill. > To get off the fork, we need to parameterize these features in sqlline and > have them driven from a properties file. The changes should be merged back > into sqlline and Drill packaging should then provide a properties file to > customize the stock sqlline distribution. > *For documentation* > SqlLine was upgraded to 1.5.0. > Added ability to customize SqlLine via drill-sqlline-override.conf file which > should be present in the classpath. > Example if placed in conf folder - drill-sqlline-override-example.conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-6768) Improve to_date, to_time and to_timestamp and corresponding cast functions to handle empty string when `drill.exec.functions.cast_empty_string_to_null` option is enable
[ https://issues.apache.org/jira/browse/DRILL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726337#comment-16726337 ] Bridget Bevens commented on DRILL-6768: --- Hi [~KazydubB], I added the note to this page with a very simple example: https://drill.apache.org/docs/data-type-conversion/ You may want to review and let me know if I should make any changes. Thanks, Bridget > Improve to_date, to_time and to_timestamp and corresponding cast functions to > handle empty string when `drill.exec.functions.cast_empty_string_to_null` > option is enabled > - > > Key: DRILL-6768 > URL: https://issues.apache.org/jira/browse/DRILL-6768 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Bohdan Kazydub >Assignee: Bohdan Kazydub >Priority: Major > Labels: doc-complete, ready-to-commit > Fix For: 1.15.0 > > > When `drill.exec.functions.cast_empty_string_to_null` option is enabled > `to_date`, `to_time` and `to_timestamp` functions while converting string to > according type in case if null or empty string values are passed will return > NULL (to avoid CASE clauses which are littering a query and will work in > accordance with their respective CAST counterparts) for both cases. > > > > CASTs will be handled in a similar way (uniformly with numeric types): > > ||Value to cast||Now||Will be|| > |NULL|NULL|NULL| > |'' (empty string)|Error in many cases (except numerical types)|NULL| > CAST empty string to null (in case of enabled option) will be supported by > DATE, TIME, TIMESTAMP, INTERVAL YEAR, INTERVAL MONTH and INTERVAL DAY > functions in addition to numeric types. > > *For documentation* > TBA -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-6825) Applying different hash function according to data types and data size
[ https://issues.apache.org/jira/browse/DRILL-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726299#comment-16726299 ] Boaz Ben-Zvi commented on DRILL-6825: - [~weijie] - When iterating, each data type vector may use a different hash function. Indeed for variable sized types (usually VARCHAR) a given hash function may not perform best if the value is long; however as these values are used as (join/aggr) keys, they are typically of a reasonable size (e.g. <= 16). If some users insists on using long keys, they deserve poor performance :) We could also have a collection of hash functions, and use some configuration map to assign each type its hash function. The suggestion to extract all the key columns into a temporary buffer and then apply a single function over this buffer also has costs, like the copy and the inflexibility of using the same hash function for all. Here is an example for a type specific hash function: For TIMESTAMP - take the MMDD part and XOR with the seed, then perform a (slower) hash on each byte of the microseconds part (the latter part usually has more entropy). > Applying different hash function according to data types and data size > -- > > Key: DRILL-6825 > URL: https://issues.apache.org/jira/browse/DRILL-6825 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Codegen >Reporter: weijie.tong >Assignee: weijie.tong >Priority: Major > Fix For: 1.16.0 > > > Different hash functions have different performance according to different > data types and data size. We should choose a right one to apply not just > Murmurhash. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-6915) Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer MacOS
[
https://issues.apache.org/jira/browse/DRILL-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726264#comment-16726264
]
Vitalii Diravka commented on DRILL-6915:
Merged to master branch with commit id 6a9465ab8238ced53f4b899b54e4ea22e3e86f11
> Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer
> MacOS
> -
>
> Key: DRILL-6915
> URL: https://issues.apache.org/jira/browse/DRILL-6915
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.15.0
> Environment: MacOS, either High Sierra (10.13) or Mojave (10.14).
>
>Reporter: Boaz Ben-Zvi
>Assignee: Volodymyr Vysotskyi
>Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> The newer MacOS file systems (10.13 and above) are case-insensitive by
> default. This leads to the following unit test failure:
> {code:java}
> ~/drill > mvn clean install -rf :drill-jdbc-storage
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: osx
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 10.14
> .
> [INFO]
>
> [INFO] Building contrib/jdbc-storage-plugin 1.15.0-SNAPSHOT
> [INFO]
>
> .
> [INFO] >> 2018-12-19 15:11:32 7136 [Warning] Setting lower_case_table_names=2
> because file system for __drill/contrib/storage-jdbc/target/mysql-data/data/
> is case insensitive
> .
> [ERROR] Failed to execute:
> create table CASESENSITIVETABLE (
> a BLOB,
> b BLOB
> )
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] contrib/jdbc-storage-plugin FAILURE [01:30
> min]
> ...
> [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute
> (create-tables) on project drill-jdbc-storage: Table 'casesensitivetable'
> already exists -> [Help 1]{code}
> in the test file *mysql-test-data.sql*, where +both+ tables
> *caseSensitiveTable* and *CASESENSITIVETABLE* are created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6915) Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer MacOS
[
https://issues.apache.org/jira/browse/DRILL-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-6915:
Labels: ready-to-commit (was: )
> Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer
> MacOS
> -
>
> Key: DRILL-6915
> URL: https://issues.apache.org/jira/browse/DRILL-6915
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.15.0
> Environment: MacOS, either High Sierra (10.13) or Mojave (10.14).
>
>Reporter: Boaz Ben-Zvi
>Assignee: Volodymyr Vysotskyi
>Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> The newer MacOS file systems (10.13 and above) are case-insensitive by
> default. This leads to the following unit test failure:
> {code:java}
> ~/drill > mvn clean install -rf :drill-jdbc-storage
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: osx
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 10.14
> .
> [INFO]
>
> [INFO] Building contrib/jdbc-storage-plugin 1.15.0-SNAPSHOT
> [INFO]
>
> .
> [INFO] >> 2018-12-19 15:11:32 7136 [Warning] Setting lower_case_table_names=2
> because file system for __drill/contrib/storage-jdbc/target/mysql-data/data/
> is case insensitive
> .
> [ERROR] Failed to execute:
> create table CASESENSITIVETABLE (
> a BLOB,
> b BLOB
> )
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] contrib/jdbc-storage-plugin FAILURE [01:30
> min]
> ...
> [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute
> (create-tables) on project drill-jdbc-storage: Table 'casesensitivetable'
> already exists -> [Help 1]{code}
> in the test file *mysql-test-data.sql*, where +both+ tables
> *caseSensitiveTable* and *CASESENSITIVETABLE* are created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-6915) Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer MacOS
[
https://issues.apache.org/jira/browse/DRILL-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726050#comment-16726050
]
Volodymyr Vysotskyi commented on DRILL-6915:
[~ben-zvi], could you please confirm that PR fixes the issue on your env?
> Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer
> MacOS
> -
>
> Key: DRILL-6915
> URL: https://issues.apache.org/jira/browse/DRILL-6915
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.15.0
> Environment: MacOS, either High Sierra (10.13) or Mojave (10.14).
>
>Reporter: Boaz Ben-Zvi
>Assignee: Volodymyr Vysotskyi
>Priority: Blocker
> Fix For: 1.15.0
>
>
> The newer MacOS file systems (10.13 and above) are case-insensitive by
> default. This leads to the following unit test failure:
> {code:java}
> ~/drill > mvn clean install -rf :drill-jdbc-storage
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: osx
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 10.14
> .
> [INFO]
>
> [INFO] Building contrib/jdbc-storage-plugin 1.15.0-SNAPSHOT
> [INFO]
>
> .
> [INFO] >> 2018-12-19 15:11:32 7136 [Warning] Setting lower_case_table_names=2
> because file system for __drill/contrib/storage-jdbc/target/mysql-data/data/
> is case insensitive
> .
> [ERROR] Failed to execute:
> create table CASESENSITIVETABLE (
> a BLOB,
> b BLOB
> )
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] contrib/jdbc-storage-plugin FAILURE [01:30
> min]
> ...
> [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute
> (create-tables) on project drill-jdbc-storage: Table 'casesensitivetable'
> already exists -> [Help 1]{code}
> in the test file *mysql-test-data.sql*, where +both+ tables
> *caseSensitiveTable* and *CASESENSITIVETABLE* are created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (DRILL-6917) Add test for DRILL-6912
[ https://issues.apache.org/jira/browse/DRILL-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Guzenko closed DRILL-6917. --- Resolution: Done Fix Version/s: 1.15.0 Part of commit: d4771219f6d15cf89f7aeab9357bc3b26d9bf052 > Add test for DRILL-6912 > --- > > Key: DRILL-6917 > URL: https://issues.apache.org/jira/browse/DRILL-6917 > Project: Apache Drill > Issue Type: Test >Reporter: Igor Guzenko >Assignee: Igor Guzenko >Priority: Minor > Fix For: 1.15.0 > > Attachments: TestTwoDrillbitsWithSamePort.java > > > Currently there is working test from attachment, but it's necessary to > migrate it into TestGracefulShutdown class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6912) NPE when another drillbit is already running
[
https://issues.apache.org/jira/browse/DRILL-6912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi updated DRILL-6912:
---
Labels: ready-to-commit (was: )
> NPE when another drillbit is already running
>
>
> Key: DRILL-6912
> URL: https://issues.apache.org/jira/browse/DRILL-6912
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Igor Guzenko
>Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> If user tries to run the second drillbit process, the following output will
> be obtained:
> {code:java}
> vitalii@vitalii-pc:/tmp/apache-drill-1.15.0$ bin/drill-embedded
> java.lang.NullPointerException
> Apache Drill 1.15.0
> "This isn't your grandfather's SQL."
> sqlline> select * from (values(1));
> No current connection
> sqlline> !q
> {code}
> For 1.14.0 drill version the output was correct (but too long):
> {code:java}
> ./bin/drill-embedded
> Dec 18, 2018 7:58:47 PM org.glassfish.jersey.server.ApplicationHandler
> initialize
> INFO: Initiating Jersey application, version Jersey: 2.8 2014-04-29
> 01:25:26...
> Error: Failure in starting embedded Drillbit: java.net.BindException: Address
> already in use (state=,code=0)
> java.sql.SQLException: Failure in starting embedded Drillbit:
> java.net.BindException: Address already in use
> at
> org.apache.drill.jdbc.impl.DrillConnectionImpl.(DrillConnectionImpl.java:143)
> at
> org.apache.drill.jdbc.impl.DrillJdbc41Factory.newDrillConnection(DrillJdbc41Factory.java:72)
> at
> org.apache.drill.jdbc.impl.DrillFactory.newConnection(DrillFactory.java:68)
> at
> org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:138)
> at org.apache.drill.jdbc.Driver.connect(Driver.java:72)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:167)
> at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:213)
> at sqlline.Commands.connect(Commands.java:1083)
> at sqlline.Commands.connect(Commands.java:1015)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
> at sqlline.SqlLine.dispatch(SqlLine.java:742)
> at sqlline.SqlLine.initArgs(SqlLine.java:528)
> at sqlline.SqlLine.begin(SqlLine.java:596)
> at sqlline.SqlLine.start(SqlLine.java:375)
> at sqlline.SqlLine.main(SqlLine.java:268)
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:279)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
> at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:218)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at org.eclipse.jetty.server.Server.doStart(Server.java:337)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at org.apache.drill.exec.server.rest.WebServer.start(WebServer.java:155)
> at org.apache.drill.exec.server.Drillbit.run(Drillbit.java:200)
> at
> org.apache.drill.jdbc.impl.DrillConnectionImpl.(DrillConnectionImpl.java:134)
> ... 18 more
> apache drill 1.14.0
> "just drill it"
> 0: jdbc:drill:zk=local> !q{code}
> Looks like it is fine to have a short message in console about the reason of
> error, similar to:
> {code:java}
> java.sql.SQLException: Failure in starting embedded Drillbit:
> java.net.BindException: Address already in use
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6915) Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer MacOS
[
https://issues.apache.org/jira/browse/DRILL-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-6915:
Fix Version/s: 1.15.0
> Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer
> MacOS
> -
>
> Key: DRILL-6915
> URL: https://issues.apache.org/jira/browse/DRILL-6915
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.15.0
> Environment: MacOS, either High Sierra (10.13) or Mojave (10.14).
>
>Reporter: Boaz Ben-Zvi
>Priority: Blocker
> Fix For: 1.15.0
>
>
> The newer MacOS file systems (10.13 and above) are case-insensitive by
> default. This leads to the following unit test failure:
> {code:java}
> ~/drill > mvn clean install -rf :drill-jdbc-storage
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: osx
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 10.14
> .
> [INFO]
>
> [INFO] Building contrib/jdbc-storage-plugin 1.15.0-SNAPSHOT
> [INFO]
>
> .
> [INFO] >> 2018-12-19 15:11:32 7136 [Warning] Setting lower_case_table_names=2
> because file system for __drill/contrib/storage-jdbc/target/mysql-data/data/
> is case insensitive
> .
> [ERROR] Failed to execute:
> create table CASESENSITIVETABLE (
> a BLOB,
> b BLOB
> )
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] contrib/jdbc-storage-plugin FAILURE [01:30
> min]
> ...
> [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute
> (create-tables) on project drill-jdbc-storage: Table 'casesensitivetable'
> already exists -> [Help 1]{code}
> in the test file *mysql-test-data.sql*, where +both+ tables
> *caseSensitiveTable* and *CASESENSITIVETABLE* are created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6915) Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer MacOS
[
https://issues.apache.org/jira/browse/DRILL-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-6915:
Reviewer: Arina Ielchiieva
> Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer
> MacOS
> -
>
> Key: DRILL-6915
> URL: https://issues.apache.org/jira/browse/DRILL-6915
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.15.0
> Environment: MacOS, either High Sierra (10.13) or Mojave (10.14).
>
>Reporter: Boaz Ben-Zvi
>Assignee: Volodymyr Vysotskyi
>Priority: Blocker
> Fix For: 1.15.0
>
>
> The newer MacOS file systems (10.13 and above) are case-insensitive by
> default. This leads to the following unit test failure:
> {code:java}
> ~/drill > mvn clean install -rf :drill-jdbc-storage
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: osx
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 10.14
> .
> [INFO]
>
> [INFO] Building contrib/jdbc-storage-plugin 1.15.0-SNAPSHOT
> [INFO]
>
> .
> [INFO] >> 2018-12-19 15:11:32 7136 [Warning] Setting lower_case_table_names=2
> because file system for __drill/contrib/storage-jdbc/target/mysql-data/data/
> is case insensitive
> .
> [ERROR] Failed to execute:
> create table CASESENSITIVETABLE (
> a BLOB,
> b BLOB
> )
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] contrib/jdbc-storage-plugin FAILURE [01:30
> min]
> ...
> [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute
> (create-tables) on project drill-jdbc-storage: Table 'casesensitivetable'
> already exists -> [Help 1]{code}
> in the test file *mysql-test-data.sql*, where +both+ tables
> *caseSensitiveTable* and *CASESENSITIVETABLE* are created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6915) Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer MacOS
[
https://issues.apache.org/jira/browse/DRILL-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-6915:
Priority: Blocker (was: Minor)
> Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer
> MacOS
> -
>
> Key: DRILL-6915
> URL: https://issues.apache.org/jira/browse/DRILL-6915
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.15.0
> Environment: MacOS, either High Sierra (10.13) or Mojave (10.14).
>
>Reporter: Boaz Ben-Zvi
>Priority: Blocker
> Fix For: 1.15.0
>
>
> The newer MacOS file systems (10.13 and above) are case-insensitive by
> default. This leads to the following unit test failure:
> {code:java}
> ~/drill > mvn clean install -rf :drill-jdbc-storage
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: osx
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 10.14
> .
> [INFO]
>
> [INFO] Building contrib/jdbc-storage-plugin 1.15.0-SNAPSHOT
> [INFO]
>
> .
> [INFO] >> 2018-12-19 15:11:32 7136 [Warning] Setting lower_case_table_names=2
> because file system for __drill/contrib/storage-jdbc/target/mysql-data/data/
> is case insensitive
> .
> [ERROR] Failed to execute:
> create table CASESENSITIVETABLE (
> a BLOB,
> b BLOB
> )
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] contrib/jdbc-storage-plugin FAILURE [01:30
> min]
> ...
> [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute
> (create-tables) on project drill-jdbc-storage: Table 'casesensitivetable'
> already exists -> [Help 1]{code}
> in the test file *mysql-test-data.sql*, where +both+ tables
> *caseSensitiveTable* and *CASESENSITIVETABLE* are created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (DRILL-6915) Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer MacOS
[
https://issues.apache.org/jira/browse/DRILL-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva reassigned DRILL-6915:
---
Assignee: Volodymyr Vysotskyi
> Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer
> MacOS
> -
>
> Key: DRILL-6915
> URL: https://issues.apache.org/jira/browse/DRILL-6915
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.15.0
> Environment: MacOS, either High Sierra (10.13) or Mojave (10.14).
>
>Reporter: Boaz Ben-Zvi
>Assignee: Volodymyr Vysotskyi
>Priority: Blocker
> Fix For: 1.15.0
>
>
> The newer MacOS file systems (10.13 and above) are case-insensitive by
> default. This leads to the following unit test failure:
> {code:java}
> ~/drill > mvn clean install -rf :drill-jdbc-storage
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: osx
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 10.14
> .
> [INFO]
>
> [INFO] Building contrib/jdbc-storage-plugin 1.15.0-SNAPSHOT
> [INFO]
>
> .
> [INFO] >> 2018-12-19 15:11:32 7136 [Warning] Setting lower_case_table_names=2
> because file system for __drill/contrib/storage-jdbc/target/mysql-data/data/
> is case insensitive
> .
> [ERROR] Failed to execute:
> create table CASESENSITIVETABLE (
> a BLOB,
> b BLOB
> )
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] contrib/jdbc-storage-plugin FAILURE [01:30
> min]
> ...
> [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute
> (create-tables) on project drill-jdbc-storage: Table 'casesensitivetable'
> already exists -> [Help 1]{code}
> in the test file *mysql-test-data.sql*, where +both+ tables
> *caseSensitiveTable* and *CASESENSITIVETABLE* are created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6916) Fix extraneous "${project.basedir}/src/site/resources/repo/" directory appearance
[
https://issues.apache.org/jira/browse/DRILL-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitalii Diravka updated DRILL-6916:
---
Description:
After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources root
directory the extraneous directory can be created in the process of {{mvn clean
install -DskipTests -pl contrib/storage-hbase/}}
It is related to absent {{maven-metadata.xml}} file in
{{org.glassfish:javax.el}} transitive dependency from HBase lib.
See info from {{mvn release:prepare -X}}:
{noformat}
[INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
file:${project.basedir}/src/site/resources/repo was cached in the local
repository, resolution will not be reattempted until the update interval of
project.local has elapsed or updates are forced{noformat}
So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
local maven repo:
{noformat}
~/.m2/repository/org/glassfish/javax.el{noformat}
and making Drill build for HBase package:
{noformat}
mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
Solution: update HBase lib to the latest 2.1.1 version, since HBASE-21005
resolved there.
was:
After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources root
directory the extraneous directory can be created in the process of {{mvn clean
install -DskipTests -pl contrib/storage-hbase/}}
It is related to absent {{maven-metadata.xml}} file in
{{org.glassfish:javax.el}} transitive dependency from HBase lib.
See info from {{mvn release:prepare -X}}:
{noformat}
[INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
file:${project.basedir}/src/site/resources/repo was cached in the local
repository, resolution will not be reattempted until the update interval of
project.local has elapsed or updates are forced{noformat}
So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
local maven repo:
{noformat}
~/.m2/repository/org/glassfish/javax.el{noformat}
and making Drill build for HBase package:
{noformat}
mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
Solution: update HBase lib to the latest 2.1.1 version, it hasn't this issue.
> Fix extraneous "${project.basedir}/src/site/resources/repo/" directory
> appearance
> -
>
> Key: DRILL-6916
> URL: https://issues.apache.org/jira/browse/DRILL-6916
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - HBase, Tools, Build Test
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources
> root directory the extraneous directory can be created in the process of
> {{mvn clean install -DskipTests -pl contrib/storage-hbase/}}
> It is related to absent {{maven-metadata.xml}} file in
> {{org.glassfish:javax.el}} transitive dependency from HBase lib.
> See info from {{mvn release:prepare -X}}:
> {noformat}
> [INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
> file:${project.basedir}/src/site/resources/repo was cached in the local
> repository, resolution will not be reattempted until the update interval of
> project.local has elapsed or updates are forced{noformat}
> So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
> local maven repo:
> {noformat}
> ~/.m2/repository/org/glassfish/javax.el{noformat}
> and making Drill build for HBase package:
> {noformat}
> mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
> Solution: update HBase lib to the latest 2.1.1 version, since HBASE-21005
> resolved there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6916) Fix extraneous "${project.basedir}/src/site/resources/repo/" directory appearance
[
https://issues.apache.org/jira/browse/DRILL-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-6916:
Labels: ready-to-commit (was: )
> Fix extraneous "${project.basedir}/src/site/resources/repo/" directory
> appearance
> -
>
> Key: DRILL-6916
> URL: https://issues.apache.org/jira/browse/DRILL-6916
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - HBase, Tools, Build Test
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.15.0
>
>
> After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources
> root directory the extraneous directory can be created in the process of
> {{mvn clean install -DskipTests -pl contrib/storage-hbase/}}
> It is related to absent {{maven-metadata.xml}} file in
> {{org.glassfish:javax.el}} transitive dependency from HBase lib.
> See info from {{mvn release:prepare -X}}:
> {noformat}
> [INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
> file:${project.basedir}/src/site/resources/repo was cached in the local
> repository, resolution will not be reattempted until the update interval of
> project.local has elapsed or updates are forced{noformat}
> So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
> local maven repo:
> {noformat}
> ~/.m2/repository/org/glassfish/javax.el{noformat}
> and making Drill build for HBase package:
> {noformat}
> mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
> Solution: update HBase lib to the latest 2.1.1 version, it hasn't this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6917) Add test for DRILL-6912
[ https://issues.apache.org/jira/browse/DRILL-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Guzenko updated DRILL-6917: Summary: Add test for DRILL-6912 (was: Add test for test case ) > Add test for DRILL-6912 > --- > > Key: DRILL-6917 > URL: https://issues.apache.org/jira/browse/DRILL-6917 > Project: Apache Drill > Issue Type: Test >Reporter: Igor Guzenko >Assignee: Igor Guzenko >Priority: Minor > Attachments: TestTwoDrillbitsWithSamePort.java > > > Currently there is working test from attachment, but it's necessary to > migrate it into TestGracefulShutdown class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6915) Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer MacOS
[
https://issues.apache.org/jira/browse/DRILL-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-6915:
Affects Version/s: (was: 1.14.0)
1.15.0
> Unit test mysql-test-data.sql in contrib/jdbc-storage-plugin fails on newer
> MacOS
> -
>
> Key: DRILL-6915
> URL: https://issues.apache.org/jira/browse/DRILL-6915
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.15.0
> Environment: MacOS, either High Sierra (10.13) or Mojave (10.14).
>
>Reporter: Boaz Ben-Zvi
>Priority: Minor
>
> The newer MacOS file systems (10.13 and above) are case-insensitive by
> default. This leads to the following unit test failure:
> {code:java}
> ~/drill > mvn clean install -rf :drill-jdbc-storage
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: osx
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 10.14
> .
> [INFO]
>
> [INFO] Building contrib/jdbc-storage-plugin 1.15.0-SNAPSHOT
> [INFO]
>
> .
> [INFO] >> 2018-12-19 15:11:32 7136 [Warning] Setting lower_case_table_names=2
> because file system for __drill/contrib/storage-jdbc/target/mysql-data/data/
> is case insensitive
> .
> [ERROR] Failed to execute:
> create table CASESENSITIVETABLE (
> a BLOB,
> b BLOB
> )
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] contrib/jdbc-storage-plugin FAILURE [01:30
> min]
> ...
> [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute
> (create-tables) on project drill-jdbc-storage: Table 'casesensitivetable'
> already exists -> [Help 1]{code}
> in the test file *mysql-test-data.sql*, where +both+ tables
> *caseSensitiveTable* and *CASESENSITIVETABLE* are created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DRILL-6917) Add test for test case
Igor Guzenko created DRILL-6917: --- Summary: Add test for test case Key: DRILL-6917 URL: https://issues.apache.org/jira/browse/DRILL-6917 Project: Apache Drill Issue Type: Test Reporter: Igor Guzenko Assignee: Igor Guzenko Attachments: TestTwoDrillbitsWithSamePort.java Currently there is working test from attachment, but it's necessary to migrate it into TestGracefulShutdown class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6916) Fix extraneous "${project.basedir}/src/site/resources/repo/" directory appearance
[
https://issues.apache.org/jira/browse/DRILL-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-6916:
Priority: Blocker (was: Minor)
Reviewer: Arina Ielchiieva
> Fix extraneous "${project.basedir}/src/site/resources/repo/" directory
> appearance
> -
>
> Key: DRILL-6916
> URL: https://issues.apache.org/jira/browse/DRILL-6916
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - HBase, Tools, Build Test
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Blocker
> Fix For: 1.15.0
>
>
> After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources
> root directory the extraneous directory can be created in the process of
> {{mvn clean install -DskipTests -pl contrib/storage-hbase/}}
> It is related to absent {{maven-metadata.xml}} file in
> {{org.glassfish:javax.el}} transitive dependency from HBase lib.
> See info from {{mvn release:prepare -X}}:
> {noformat}
> [INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
> file:${project.basedir}/src/site/resources/repo was cached in the local
> repository, resolution will not be reattempted until the update interval of
> project.local has elapsed or updates are forced{noformat}
> So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
> local maven repo:
> {noformat}
> ~/.m2/repository/org/glassfish/javax.el{noformat}
> and making Drill build for HBase package:
> {noformat}
> mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
> Solution: update HBase lib to the latest 2.1.1 version, it hasn't this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6916) Fix extraneous "${project.basedir}/src/site/resources/repo/" directory appearance
[
https://issues.apache.org/jira/browse/DRILL-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitalii Diravka updated DRILL-6916:
---
Summary: Fix extraneous "${project.basedir}/src/site/resources/repo/"
directory appearance (was: "${project.basedir}/src/site/resources/repo/"
extraneous directory in Drill sources)
> Fix extraneous "${project.basedir}/src/site/resources/repo/" directory
> appearance
> -
>
> Key: DRILL-6916
> URL: https://issues.apache.org/jira/browse/DRILL-6916
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - HBase, Tools, Build Test
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Minor
> Fix For: 1.15.0
>
>
> After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources
> root directory the extraneous directory can be created in the process of
> {{mvn clean install -DskipTests -pl contrib/storage-hbase/}}
> It is related to absent {{maven-metadata.xml}} file in
> {{org.glassfish:javax.el}} transitive dependency from HBase lib.
> See info from {{mvn release:prepare -X}}:
> {noformat}
> [INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
> file:${project.basedir}/src/site/resources/repo was cached in the local
> repository, resolution will not be reattempted until the update interval of
> project.local has elapsed or updates are forced{noformat}
> So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
> local maven repo:
> {noformat}
> ~/.m2/repository/org/glassfish/javax.el{noformat}
> and making Drill build for HBase package:
> {noformat}
> mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
> Solution: update HBase lib to the latest 2.1.1 version, it hasn't this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6907) Fix hive-exec-shaded classes recognition in IntelliJ IDEA
[ https://issues.apache.org/jira/browse/DRILL-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitalii Diravka updated DRILL-6907: --- Labels: ready-to-commit (was: ) > Fix hive-exec-shaded classes recognition in IntelliJ IDEA > - > > Key: DRILL-6907 > URL: https://issues.apache.org/jira/browse/DRILL-6907 > Project: Apache Drill > Issue Type: Task > Components: Tools, Build Test >Affects Versions: 1.14.0 >Reporter: Volodymyr Vysotskyi >Assignee: Volodymyr Vysotskyi >Priority: Minor > Labels: ready-to-commit > Fix For: 1.16.0 > > > Classes from `hive-exec-shaded` module are not recognized by IntelliJ IDEA. > The solution is to attach the shaded jar to the project using > `build-helper-maven-plugin`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6916) "${project.basedir}/src/site/resources/repo/" extraneous directory in Drill sources
[
https://issues.apache.org/jira/browse/DRILL-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitalii Diravka updated DRILL-6916:
---
Issue Type: Bug (was: Improvement)
> "${project.basedir}/src/site/resources/repo/" extraneous directory in Drill
> sources
> ---
>
> Key: DRILL-6916
> URL: https://issues.apache.org/jira/browse/DRILL-6916
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - HBase, Tools, Build Test
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Minor
> Fix For: 1.15.0
>
>
> After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources
> root directory the extraneous directory can be created in the process of
> {{mvn clean install -DskipTests -pl contrib/storage-hbase/}}
> It is related to absent {{maven-metadata.xml}} file in
> {{org.glassfish:javax.el}} transitive dependency from HBase lib.
> See info from {{mvn release:prepare -X}}:
> {noformat}
> [INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
> file:${project.basedir}/src/site/resources/repo was cached in the local
> repository, resolution will not be reattempted until the update interval of
> project.local has elapsed or updates are forced{noformat}
> So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
> local maven repo:
> {noformat}
> ~/.m2/repository/org/glassfish/javax.el{noformat}
> and making Drill build for HBase package:
> {noformat}
> mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
> Solution: update HBase lib to the latest 2.1.1 version, it hasn't this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6916) "${project.basedir}/src/site/resources/repo/" extraneous directory in Drill sources
[
https://issues.apache.org/jira/browse/DRILL-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitalii Diravka updated DRILL-6916:
---
Priority: Minor (was: Major)
> "${project.basedir}/src/site/resources/repo/" extraneous directory in Drill
> sources
> ---
>
> Key: DRILL-6916
> URL: https://issues.apache.org/jira/browse/DRILL-6916
> Project: Apache Drill
> Issue Type: Improvement
> Components: Storage - HBase, Tools, Build Test
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Minor
> Fix For: 1.15.0
>
>
> After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources
> root directory the extraneous directory can be created in the process of
> {{mvn clean install -DskipTests -pl contrib/storage-hbase/}}
> It is related to absent {{maven-metadata.xml}} file in
> {{org.glassfish:javax.el}} transitive dependency from HBase lib.
> See info from {{mvn release:prepare -X}}:
> {noformat}
> [INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
> file:${project.basedir}/src/site/resources/repo was cached in the local
> repository, resolution will not be reattempted until the update interval of
> project.local has elapsed or updates are forced{noformat}
> So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
> local maven repo:
> {noformat}
> ~/.m2/repository/org/glassfish/javax.el{noformat}
> and making Drill build for HBase package:
> {noformat}
> mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
> Solution: update HBase lib to the latest 2.1.1 version, it hasn't this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6916) "${project.basedir}/src/site/resources/repo/" extraneous directory in Drill sources
[
https://issues.apache.org/jira/browse/DRILL-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitalii Diravka updated DRILL-6916:
---
Component/s: Storage - HBase
> "${project.basedir}/src/site/resources/repo/" extraneous directory in Drill
> sources
> ---
>
> Key: DRILL-6916
> URL: https://issues.apache.org/jira/browse/DRILL-6916
> Project: Apache Drill
> Issue Type: Improvement
> Components: Storage - HBase, Tools, Build Test
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Major
> Fix For: 1.15.0
>
>
> After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources
> root directory the extraneous directory can be created in the process of
> {{mvn clean install -DskipTests -pl contrib/storage-hbase/}}
> It is related to absent {{maven-metadata.xml}} file in
> {{org.glassfish:javax.el}} transitive dependency from HBase lib.
> See info from {{mvn release:prepare -X}}:
> {noformat}
> [INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
> file:${project.basedir}/src/site/resources/repo was cached in the local
> repository, resolution will not be reattempted until the update interval of
> project.local has elapsed or updates are forced{noformat}
> So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
> local maven repo:
> {noformat}
> ~/.m2/repository/org/glassfish/javax.el{noformat}
> and making Drill build for HBase package:
> {noformat}
> mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
> Solution: update HBase lib to the latest 2.1.1 version, it hasn't this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DRILL-6916) "${project.basedir}/src/site/resources/repo/" extraneous directory in Drill sources
Vitalii Diravka created DRILL-6916:
--
Summary: "${project.basedir}/src/site/resources/repo/" extraneous
directory in Drill sources
Key: DRILL-6916
URL: https://issues.apache.org/jira/browse/DRILL-6916
Project: Apache Drill
Issue Type: Improvement
Components: Tools, Build Test
Affects Versions: 1.15.0
Reporter: Vitalii Diravka
Assignee: Vitalii Diravka
Fix For: 1.15.0
After upgrade HBase lib (in scope of DRILL-6349) in Drill project sources root
directory the extraneous directory can be created in the process of {{mvn clean
install -DskipTests -pl contrib/storage-hbase/}}
It is related to absent {{maven-metadata.xml}} file in
{{org.glassfish:javax.el}} transitive dependency from HBase lib.
See info from {{mvn release:prepare -X}}:
{noformat}
[INFO] [DEBUG] Failure to find org.glassfish:javax.el/maven-metadata.xml in
file:${project.basedir}/src/site/resources/repo was cached in the local
repository, resolution will not be reattempted until the update interval of
project.local has elapsed or updates are forced{noformat}
So it can be easily reproduced with removing {{org.glassfish:javax.el}} from
local maven repo:
{noformat}
~/.m2/repository/org/glassfish/javax.el{noformat}
and making Drill build for HBase package:
{noformat}
mvn clean install -DskipTests -pl contrib/storage-hbase/{noformat}
Solution: update HBase lib to the latest 2.1.1 version, it hasn't this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
