[GitHub] drill issue #685: Drill 5043: Function that returns a unique id per session/...

[nagarajanchinnasamy]

Github user nagarajanchinnasamy commented on the issue:

https://github.com/apache/drill/pull/685
  
@arina-ielchiieva 

  - minor changes made
  - commit message amended
  - unit tests added

But am not sure If I have done the squashing correctly!!! tried `rebase` 
etc.. Need help regarding this.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request #677: DRILL-5065 - Optimize count( * ) queries on MapR-DB...

[spanchamiamapr]

Github user spanchamiamapr closed the pull request at:

https://github.com/apache/drill/pull/677


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (DRILL-5130) UNION ALL difference in results

[Khurram Faraaz (JIRA)]

Khurram Faraaz created DRILL-5130:
-

 Summary: UNION ALL difference in results
 Key: DRILL-5130
 URL: https://issues.apache.org/jira/browse/DRILL-5130
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Flow
Affects Versions: 1.9.0
Reporter: Khurram Faraaz


Drill 1.9.0 git commit ID: 51246693

{noformat}
0: jdbc:drill:schema=dfs.tmp> values(1,2,3,4,5,6) union all 
values(7,8,9,10,11,12);
+-+-+-+-+-+-+
| EXPR$0  | EXPR$1  | EXPR$2  | EXPR$3  | EXPR$4  | EXPR$5  |
+-+-+-+-+-+-+
| 7   | 8   | 9   | 10  | 11  | 12  |
| 7   | 8   | 9   | 10  | 11  | 12  |
+-+-+-+-+-+-+
2 rows selected (0.209 seconds)
{noformat}

Postgres 9.3

{noformat}
postgres=# values(1,2,3,4,5,6) union all values(7,8,9,10,11,12);
 column1 | column2 | column3 | column4 | column5 | column6 
-+-+-+-+-+-
   1 |   2 |   3 |   4 |   5 |   6
   7 |   8 |   9 |  10 |  11 |  12
(2 rows)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cast to date - different result on sqlline vs on Web UI

[Khurram Faraaz]

Hi All,

I am on Drill 1.9.0 git commit ID: 51246693
Why does Drill return different result on sqlline vs when run on Web UI ?

{noformat}
postgres=# SELECT (CASE WHEN (false) THEN null ELSE cast('2016/09/22' as
date) END) res1 FROM (VALUES(1)) subquery;

res1



 2016-09-22

(1 row)

{noformat}
This is from sqlline prompt

0: jdbc:drill:schema=dfs.tmp> SELECT (CASE WHEN (false) THEN null ELSE
cast('2016/09/22' as date) END) res1 FROM (VALUES(1)) subquery;

*+-+*

*| **   res1** |*

*+-+*

*| *2016-09-22 * |*

*+-+*

1 row selected (0.336 seconds)


However from Drill's Web UI, we get a different result note the T00:00:00.000Z,
at the end of date string.

SELECT (CASE WHEN (false) THEN null ELSE cast('2016/09/22' as date) END)
res1 FROM (VALUES(1)) subquery;

res1

2016-09-22T00:00:00.000Z

Thanks,
Khurram

[GitHub] drill issue #662: DRILL-5051: Fix incorrect result returned in nest query wi...

[zbdzzg]

Github user zbdzzg commented on the issue:

https://github.com/apache/drill/pull/662
  
@sudheeshkatkam Could you please review this? Thanks.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request #696: DRILL-4558: BSonReader should prepare buffer size a...

[chunhui-shi]

GitHub user chunhui-shi opened a pull request:

https://github.com/apache/drill/pull/696

DRILL-4558: BSonReader should prepare buffer size as actual need



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/chunhui-shi/drill DRILL-4558

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/696.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #696


commit fc0b7478efef1447ccca8965c8da001a04f243d4
Author: chunhui-shi 
Date:   2016-12-14T02:00:49Z

DRILL-4558: BSonReader should prepare buffer size as actual need




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request #695: DRILL-4868: fix how hive function set DrillBuf.

[chunhui-shi]

GitHub user chunhui-shi opened a pull request:

https://github.com/apache/drill/pull/695

DRILL-4868: fix how hive function set DrillBuf.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/chunhui-shi/drill DRILL-4868

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/695.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #695


commit 54334558b63c4f15e66bbb88f639911d56e04cb9
Author: chunhui-shi 
Date:   2016-12-13T23:16:40Z

DRILL-4868: fix how hive function set DrillBuf.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (DRILL-5129) Use SilentListener in DrillSeparatePlanningTest

[Sudheesh Katkam (JIRA)]

Sudheesh Katkam created DRILL-5129:
--

 Summary: Use SilentListener in DrillSeparatePlanningTest
 Key: DRILL-5129
 URL: https://issues.apache.org/jira/browse/DRILL-5129
 Project: Apache Drill
  Issue Type: Improvement
  Components: Tools, Build & Test
Reporter: Sudheesh Katkam
Assignee: Sudheesh Katkam
Priority: Minor


[DrillSeparatePlanningTest.java|https://github.com/apache/drill/blob/master/exec/java-exec/src/test/java/org/apache/drill/exec/DrillSeparatePlanningTest.java#L184]
 should use SilentListener in all tests, instead of PrintingResultsListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] drill issue #679: DRILL-5098: Improving fault tolerance for connection betwe...

[sudheeshkatkam]

Github user sudheeshkatkam commented on the issue:

https://github.com/apache/drill/pull/679
  
+1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request #679: DRILL-5098: Improving fault tolerance for connectio...

[sohami]

Github user sohami commented on a diff in the pull request:

https://github.com/apache/drill/pull/679#discussion_r92296665
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/client/DrillClient.java ---
@@ -357,10 +357,53 @@ protected void afterExecute(final Runnable r, final 
Throwable t) {
 super.afterExecute(r, t);
   }
 };
-client = new UserClient(clientName, config, supportComplexTypes, 
allocator, eventLoopGroup, executor);
-logger.debug("Connecting to server {}:{}", endpoint.getAddress(), 
endpoint.getUserPort());
-connect(endpoint);
-connected = true;
+
+// "tries" is max number of unique drillbit to try connecting until 
successfully connected to one of them
+final String connectTriesConf = (props != null) ? 
props.getProperty("tries", "5") : "5";
+
+int connectTriesVal;
+try {
+  connectTriesVal = Math.min(endpoints.size(), 
Integer.parseInt(connectTriesConf));
+} catch (NumberFormatException e) {
+  throw new InvalidConnectionInfoException("Invalid tries value: " + 
connectTriesConf + " specified in " +
+   "connection string");
+}
+
+// If the value provided in the connection string is <=0 then override 
with 1 since we want to try connecting
+// at least once
+connectTriesVal = Math.max(1, connectTriesVal);
+
+int triedEndpointIndex = 0;
+DrillbitEndpoint endpoint;
+
+while (triedEndpointIndex < connectTriesVal) {
+  client = new UserClient(clientName, config, supportComplexTypes, 
allocator, eventLoopGroup, executor);
+  endpoint = endpoints.get(triedEndpointIndex);
+  logger.debug("Connecting to server {}:{}", endpoint.getAddress(), 
endpoint.getUserPort());
+
+  try {
+connect(endpoint);
+connected = true;
+logger.info("Successfully connected to server {}:{}", 
endpoint.getAddress(), endpoint.getUserPort());
+break;
+  } catch (InvalidConnectionInfoException ex) {
+logger.error("Connection to {}:{} failed with error {}. Not 
retrying anymore", endpoint.getAddress(),
+ endpoint.getUserPort(), ex.getMessage());
+throw ex;
+  } catch (RpcException ex) {
+++triedEndpointIndex;
+logger.error("Attempt {}: Failed to connect to server {}:{}", 
triedEndpointIndex, endpoint.getAddress(),
+ endpoint.getUserPort());
+
+// Close the connection
+client.close();
--- End diff --

I didn't found anywhere in documentation specifying the cause of calling 
close multiple times. It just says that internally close is being called for 
each handler in the pipeline. 
https://netty.io/4.0/api/io/netty/channel/Channel.html#close()

Though I do have unit tests which will result in covering that code path 
where close will be called twice. Didn't found any issue running the test. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill issue #690: DRILL-5121 A memory leak is observed when exact case is no...

[jinfengni]

Github user jinfengni commented on the issue:

https://github.com/apache/drill/pull/690
  
The proposed change looks fine for case insensitive store. On the other 
hand, have you given some thoughts of @Ben-Zvi 's comment about case sensitive 
store? Will it work for case sensitive store?

You may add one simple testcase to verify that the fix works as expected. 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request #686: DRILL-5117: Compile error when query a json file wi...

[jinfengni]

Github user jinfengni commented on a diff in the pull request:

https://github.com/apache/drill/pull/686#discussion_r92290434
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/expr/SizedJBlock.java ---
@@ -32,7 +32,11 @@
 
   public SizedJBlock(JBlock block) {
 this.block = block;
-this.count = 0;
+// count should be 1 because in some cases it is hard to increase it 
when
+// Logical Expressions are added to JBlock.
+// To avoid taking into account of some extra count from empty JBlock,
--- End diff --

I spent some time to understand why modifying this count makes the query 
compilation works.  

The failing case encounter compilation failure in Copier (for SVR 
operator). Turns out that the idea of SizedJBlock (DRILL-4715) only works when 
we call ClassGenerator.addExpr(). This is fine with Project, Filter, 
Aggregator, etc, but not for Copier.  The Copier is doing kind of short-cut 
handling, by accessing the eval() and setup() directly [1].

Ideally, we probably should try to see if we can convert Copier using same 
mechanism in Project/Filter. After some thoughts, I realized doing that might 
add additional overhead, as the current way is doing the copying directly. 

Given that, I'm fine with this proposed change. Please add comments to 
explain why we set count = 1. 

[1] 
https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/vector/CopyUtil.java#L45-L50
  


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request #686: DRILL-5117: Compile error when query a json file wi...

[jinfengni]

Github user jinfengni commented on a diff in the pull request:

https://github.com/apache/drill/pull/686#discussion_r92292702
  
--- Diff: 
exec/java-exec/src/test/java/org/apache/drill/exec/compile/TestLargeFileCompilation.java
 ---
@@ -154,4 +158,20 @@ public void testProject() throws Exception {
 testNoResult(ITERATION_COUNT, LARGE_QUERY_SELECT_LIST);
   }
 
+  @Test
+  public void testSelectAllFromFileWithManyColumns() throws Exception {
+File path = new File(BaseTestQuery.getTempDir("json/input"));
--- End diff --

You do not have to generate a new json file for writing a unit test. Not 
sure how the new created file is cleaned up if the testcase failed.

You may consider using the existing tpch sample file to do unit test, or 
re-enable the originally ignored test (testTOP_N_SORT).

```java
  @Test
  public void testLargeListColWithLimit() throws Exception {
final int nCol = 1000;
final StringBuilder sb = new StringBuilder();

sb.append(" select n_nationkey ");
for (int i = 0; i< nCol; i++) {
  sb.append(", " + "Col" + i );
}
sb.append(" from cp.`tpch/nation.parquet`");
sb.append(" limit 1");

test(sb.toString());
  }
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill issue #692: DRILL-5123: Write query profile after sending final respon...

[sudheeshkatkam]

Github user sudheeshkatkam commented on the issue:

https://github.com/apache/drill/pull/692
  
+1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request #679: DRILL-5098: Improving fault tolerance for connectio...

[sudheeshkatkam]

Github user sudheeshkatkam commented on a diff in the pull request:

https://github.com/apache/drill/pull/679#discussion_r92291348
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/client/DrillClient.java ---
@@ -357,10 +357,53 @@ protected void afterExecute(final Runnable r, final 
Throwable t) {
 super.afterExecute(r, t);
   }
 };
-client = new UserClient(clientName, config, supportComplexTypes, 
allocator, eventLoopGroup, executor);
-logger.debug("Connecting to server {}:{}", endpoint.getAddress(), 
endpoint.getUserPort());
-connect(endpoint);
-connected = true;
+
+// "tries" is max number of unique drillbit to try connecting until 
successfully connected to one of them
+final String connectTriesConf = (props != null) ? 
props.getProperty("tries", "5") : "5";
+
+int connectTriesVal;
+try {
+  connectTriesVal = Math.min(endpoints.size(), 
Integer.parseInt(connectTriesConf));
+} catch (NumberFormatException e) {
+  throw new InvalidConnectionInfoException("Invalid tries value: " + 
connectTriesConf + " specified in " +
+   "connection string");
+}
+
+// If the value provided in the connection string is <=0 then override 
with 1 since we want to try connecting
+// at least once
+connectTriesVal = Math.max(1, connectTriesVal);
+
+int triedEndpointIndex = 0;
+DrillbitEndpoint endpoint;
+
+while (triedEndpointIndex < connectTriesVal) {
+  client = new UserClient(clientName, config, supportComplexTypes, 
allocator, eventLoopGroup, executor);
+  endpoint = endpoints.get(triedEndpointIndex);
+  logger.debug("Connecting to server {}:{}", endpoint.getAddress(), 
endpoint.getUserPort());
+
+  try {
+connect(endpoint);
+connected = true;
+logger.info("Successfully connected to server {}:{}", 
endpoint.getAddress(), endpoint.getUserPort());
+break;
+  } catch (InvalidConnectionInfoException ex) {
+logger.error("Connection to {}:{} failed with error {}. Not 
retrying anymore", endpoint.getAddress(),
+ endpoint.getUserPort(), ex.getMessage());
+throw ex;
+  } catch (RpcException ex) {
+++triedEndpointIndex;
+logger.error("Attempt {}: Failed to connect to server {}:{}", 
triedEndpointIndex, endpoint.getAddress(),
+ endpoint.getUserPort());
+
+// Close the connection
+client.close();
--- End diff --

Is `UserClient#close` idempotent?

Looks like `if (triedEndpointIndex == connectTriesVal)`, then 
`UserClient#close` is called twice, here and in `DrillClient#close`. The is 
unlike the previous catch clause i.e. `catch (InvalidConnectionInfoException 
ex)`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request #694: DRILL-5104: Foreman should not alter physical plan ...

[paul-rogers]

GitHub user paul-rogers opened a pull request:

https://github.com/apache/drill/pull/694

DRILL-5104: Foreman should not alter physical plan memory

Foreman should not set external sort memory for a physical plan

Physical plans include a plan for memory allocations. However, the code
path in Foreman replans external sort memory, even for a physical plan.
This makes it impossible to use a physical plan to test memory
configuration.

This change avoids changing memory settings in a physical plan; while
preserving the adjustments for logical plans or SQL queries.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paul-rogers/drill DRILL-5104

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/694.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #694


commit 9c99c453cf4e7eeef4ca61a127caf8b79cdb3fb9
Author: Paul Rogers 
Date:   2016-12-13T22:36:42Z

DRILL-5104: Foreman should not set external sort memory for a physical plan

Physical plans include a plan for memory allocations. However, the code
path in Foreman replans external sort memory, even for a physical plan.
This makes it impossible to use a physical plan to test memory
configuration.

This change avoids changing memory settings in a physical plan; while
preserving the adjustments for logical plans or SQL queries.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Apache Drill Hangout minutes - 2016-12-13

[Parth Chandra]

Attendees: Arina, Boaz, Chunhui, Gautam, Karthikeyan, Khurram, Padma,
Parth, Roman, Paul, Serhiy, Sonny, Vitalii.

Serhiy - JIRA status workflow suggestion: admin can create workflows. Needs
to be a Apache infrastructure person to change this and we don't know how
easy it will be.

Karthik - Netty version should be upgraded. WE cannot do this because there
is problem with increased memory usage that is fixed only in the version
Drill uses. Subsequent releases of Netty undid the change. We need to try
out the new versions and if the problem has been reintroduced, work with
the Netty team to get it fixed.

Khurram - Question about Calcite rebase; many recent issues logged in Drill
have been fixed in Calcite. Roman testing dynamic UDFs, then will work on
Calcite.

Vitalii - Hive UDFs. built in functions especially date functions, can be
used by different storage plugins, but cannot use it from the test
methods.  Can use this only in the hive module, which is expected.

Sonny - Student data 12-15K universities, schools. Building a data lake,
and running analytics.  Looking at using filter pushdown capabilities.

Arina - design doc repository.
Temp tables - design doc is now on gist. Can we create a doc hub for Drill?
Or put into a gist doc and contributors can submit pull request.  We should
put the docs where they are archived. Also where they can be reviewed
easily.
Current best method - google docs, then after review in the contributors
github gist. Suggestion to put these docs in the Apache github.

Arina - temp tables
Is it worth creating a user specific temporary workspace? Can create any
tables, etc., but temp tables always only go here. If the user workspace
does not exist, temp tables to to temp workspace. Concerns about creating
tables in user workspace that can cause re-computation of statistics. Paul,
Arina will discuss offline.
Two temp tables with the same name as a persistent table (that might
already exist). Currently allowing it, and if both exist, then give the
temp table precedence. Concern that this is not right as there is no way to
really disambiguate.

Re: hangout starting in a bit

[Parth Chandra]

hangout is on:
https://plus.google.com/hangouts/_/event/ci4rdiju8bv04a64efj5fedd0lc


On Tue, Dec 13, 2016 at 10:02 AM, Khurram Faraaz 
wrote:

> Can we please have the link to the hangout ?
>
> On Tue, Dec 13, 2016 at 11:32 PM, Parth Chandra  wrote:
>
> >
> >
>

Re: hangout starting in a bit

[Khurram Faraaz]

Can we please have the link to the hangout ?

On Tue, Dec 13, 2016 at 11:32 PM, Parth Chandra  wrote:

>
>

hangout starting in a bit

[Parth Chandra]

[jira] [Created] (DRILL-5128) Issue with unable to create parquet file on dfs workspace

[David Smith (JIRA)]

David Smith created DRILL-5128:
--

 Summary: Issue with unable to create parquet file on dfs workspace
 Key: DRILL-5128
 URL: https://issues.apache.org/jira/browse/DRILL-5128
 Project: Apache Drill
  Issue Type: Bug
  Components: Storage - Parquet
Affects Versions: 1.9.0
 Environment: docker instance built on harisekhon/apache-drill
Reporter: David Smith


Unable to write a parquet file to dfs workspace with CTAS from an Oracle query.

Oracle querying works fine using ojdbc6.jar in /jars/3rdparty and configured 
via enabled storage plugin

Created dfs "data" folder and storage workspace:
{quote}
drwxr-xr-x3 root root  4096 Dec 13 16:28 data
{quote}
{quote}
"data": {
  "location": "/data",
  "writable": true,
  "defaultInputFormat": null
},
{
{quote}
and set up to use it:
{quote}
use dfs.data;
alter session set `store.format` = 'parquet'
{quote}
and then used CTAS to query Oracle for a test sample to write out:
{quote}
create table dfs.data.tsdtest1 as select * from enviroi.D_EF_FAC.FRS_INTEREST 
where INTEREST_TYPE = 'TSD' LIMIT 10;
{quote}
Which then throws the error
{quote}
Exception in thread "drill-executor-28" java.lang.NoClassDefFoundError: Could 
not initialize class org.xerial.snappy.Snappy
at 
org.apache.parquet.hadoop.DirectCodecFactory$SnappyCompressor.compress(DirectCodecFactory.java:290)
at 
org.apache.parquet.hadoop.ColumnChunkPageWriteStore$ColumnChunkPageWriter.writePage(ColumnChunkPageWriteStore.java:94)
at 
org.apache.parquet.column.impl.ColumnWriterV1.writePage(ColumnWriterV1.java:154)
at org.apache.parquet.column.impl.ColumnWriterV1.flush(ColumnWriterV1.ja
va:242)
at 
org.apache.parquet.column.impl.ColumnWriteStoreV1.flush(ColumnWriteStoreV1.java:129)
at org.apache.drill.exec.store.parquet.ParquetRecordWriter.flush(Parquet
RecordWriter.java:253)
at org.apache.drill.exec.store.parquet.ParquetRecordWriter.cleanup(Parqu
etRecordWriter.java:381)
at org.apache.drill.exec.physical.impl.WriterRecordBatch.closeWriter(Wri
terRecordBatch.java:180)
at org.apache.drill.exec.physical.impl.WriterRecordBatch.innerNext(Write
rRecordBatch.java:128)
at org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordB
atch.java:162)
at org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordB
atch.java:119)
at org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordB
atch.java:109)
at org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(Abst
ractSingleRecordBatch.java:51)
at org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerN
ext(ProjectRecordBatch.java:135)
at org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordB
atch.java:162)
at org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.ja
va:104)
at org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNex
t(ScreenCreator.java:81)
at org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.ja
va:94)
at org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentEx
ecutor.java:232)
at 
org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:226)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at 
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
at 
org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:226)
at 
org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:617)
at java.lang.Thread.run(Thread.java:745)
Error: SYSTEM ERROR: IOException: The file being written is in an invalid 
state. Probably caused by an error thrown previously. Current state: BLOCK

Fragment 0:0

[Error Id: 23f78b7e-f15c-461a-8179-2738ebfcf4a7 on 8637c49541d:31010] 
(state=,code=0)
{quote}
The process did create \data\tsdtest1 with a file, 0_0_0.parquet:
{quote}
bash-4.3# ls -l tsdtest1
total 0
-rw-r--r--1 root root 0 Dec 13 16:28 0_0_0.parquet
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)