[jira] [Comment Edited] (DRILL-5068) Add a new system table for completed profiles
[ https://issues.apache.org/jira/browse/DRILL-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816911#comment-15816911 ] Hongze Zhang edited comment on DRILL-5068 at 1/11/17 7:14 AM: -- Basically, It is a way for user to jump from system table result to detailed profile page directly on the drill Web UI. The hyperlink can be clickable in the Freemarker generated view, and will not be working on JDBC client. Without given a link, users have to copy and paste the queryID to the tail of profile page url to open the detail page. Do you think JDBC users may be confused about this column? It is indeed not pretty printed on console (http flags will be shown there). was (Author: zbdzzg): Basically, It is a way for user to jump from system table result to detailed profile page directly on the drill Web UI. The hyperlink can be clickable in the Freemarker generated view, and will not be working on JDBC client. Without given a link, users have to copy and paste the queryID to the tail of profile page url to open the detail page. Do you think JDBC users may be confused about this column? It is indeed not pretty printed on console (http flags will be show there). > Add a new system table for completed profiles > - > > Key: DRILL-5068 > URL: https://issues.apache.org/jira/browse/DRILL-5068 > Project: Apache Drill > Issue Type: Improvement > Components: Storage - Information Schema >Affects Versions: 1.8.0 > Environment: Fedora 25 > OpenJDK 8 > Firefox 50.0 >Reporter: Hongze Zhang >Assignee: Hongze Zhang > Fix For: Future > > > Hi, > Currently the profile page on UI is still not detailed enough for some > complicated uses (eg. show all failed queries during these three days), we > can only access latest 100 query profiles on this page. > We may sometimes need a specific system table for querying completed profiles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5068) Add a new system table for completed profiles
[ https://issues.apache.org/jira/browse/DRILL-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816911#comment-15816911 ] Hongze Zhang commented on DRILL-5068: - Basically, It is a way for user to jump from system table result to detailed profile page directly on the drill Web UI. The hyperlink can be clickable in the Freemarker generated view, and will not be working on JDBC client. Without given a link, users have to copy and paste the queryID to the tail of profile page url to open the detail page. Do you think JDBC users may be confused about this column? It is indeed not pretty printed on console (http flags will be show there). > Add a new system table for completed profiles > - > > Key: DRILL-5068 > URL: https://issues.apache.org/jira/browse/DRILL-5068 > Project: Apache Drill > Issue Type: Improvement > Components: Storage - Information Schema >Affects Versions: 1.8.0 > Environment: Fedora 25 > OpenJDK 8 > Firefox 50.0 >Reporter: Hongze Zhang >Assignee: Hongze Zhang > Fix For: Future > > > Hi, > Currently the profile page on UI is still not detailed enough for some > complicated uses (eg. show all failed queries during these three days), we > can only access latest 100 query profiles on this page. > We may sometimes need a specific system table for querying completed profiles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816907#comment-15816907
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user asfgit closed the pull request at:
https://github.com/apache/drill/pull/716
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
> Fix For: 1.10.0
>
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-5190) Display planning time for a query in its profile page
[ https://issues.apache.org/jira/browse/DRILL-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kunal Khatua reassigned DRILL-5190: --- Assignee: Kunal Khatua > Display planning time for a query in its profile page > - > > Key: DRILL-5190 > URL: https://issues.apache.org/jira/browse/DRILL-5190 > Project: Apache Drill > Issue Type: Bug > Components: Web Server >Affects Versions: 1.9.0 >Reporter: Kunal Khatua >Assignee: Kunal Khatua > > Currently, the Web UI does not display the time spent in planning for a query > in its profile page. The estimate needs to be done by seeing how late did the > earliest major fragment start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5068) Add a new system table for completed profiles
[ https://issues.apache.org/jira/browse/DRILL-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816805#comment-15816805 ] Kunal Khatua commented on DRILL-5068: - [~zbdzzg] Is there a reason you are generating the hyperlink in the table itself? Ideally, the system table should be just a data object that a JDBC client like SQLLine can query, or a UI layer (like Freemarker) can build and present the model. > Add a new system table for completed profiles > - > > Key: DRILL-5068 > URL: https://issues.apache.org/jira/browse/DRILL-5068 > Project: Apache Drill > Issue Type: Improvement > Components: Storage - Information Schema >Affects Versions: 1.8.0 > Environment: Fedora 25 > OpenJDK 8 > Firefox 50.0 >Reporter: Hongze Zhang >Assignee: Hongze Zhang > Fix For: Future > > > Hi, > Currently the profile page on UI is still not detailed enough for some > complicated uses (eg. show all failed queries during these three days), we > can only access latest 100 query profiles on this page. > We may sometimes need a specific system table for querying completed profiles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816673#comment-15816673
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user jinfengni commented on the issue:
https://github.com/apache/drill/pull/716
+1
The patch looks good to me. Thanks for the PR, @paul-rogers !
I'll squash and re-run the regression, before merge it to master branch.
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816672#comment-15816672
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95490516
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/ClassBuilder.java ---
@@ -64,36 +67,33 @@
* local variables. Have fun!
*
*
- * Note: not all generated code is ready to be compiled as plain-old
- * Java. Some classes omit from the template the proper throws
- * declarations. Other minor problems may also crop up. All are easy
- * to fix. Once you've done so, add the following to mark that you've
- * done the clean-up:
- * cg.plainOldJavaCapable(true); // Class supports plain-old Java
+ * Most generated classes have been upgraded to support Plain-old Java
+ * compilation. Once this work is complete, the calls to
+ * plainOldJavaCapable can be removed as all generated classes
+ * will be capable.
*
- * The setting to prefer plain-old Java is ignored for generated
+ * The setting to prefer plain-old Java is ignored for any remaining
generated
* classes not marked as plain-old Java capable.
*/
public class ClassBuilder {
- public static final String SAVE_CODE_OPTION = CodeCompiler.COMPILE_BASE
+ ".save_source";
public static final String CODE_DIR_OPTION = CodeCompiler.COMPILE_BASE +
".code_dir";
private final DrillConfig config;
private final OptionManager options;
- private final boolean saveCode;
private final File codeDir;
public ClassBuilder(DrillConfig config, OptionManager optionManager) {
this.config = config;
options = optionManager;
-// The option to save code is a boot-time option because
-// it is used selectively during debugging, but can cause
-// excessive I/O in a running server if used to save all code.
+// Code can be saved per-class to enable debugging.
+// Just mark the code generator as to be persisted,
+// point your debugger to the directory set below, and you
--- End diff --
It's probably fine to leave as it is now with proper document usage. If
more people uses this feature and run into the class name difference issue, we
can do that at that time.
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816481#comment-15816481
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95468443
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/ClassBuilder.java ---
@@ -64,36 +67,33 @@
* local variables. Have fun!
*
*
- * Note: not all generated code is ready to be compiled as plain-old
- * Java. Some classes omit from the template the proper throws
- * declarations. Other minor problems may also crop up. All are easy
- * to fix. Once you've done so, add the following to mark that you've
- * done the clean-up:
- * cg.plainOldJavaCapable(true); // Class supports plain-old Java
+ * Most generated classes have been upgraded to support Plain-old Java
+ * compilation. Once this work is complete, the calls to
+ * plainOldJavaCapable can be removed as all generated classes
+ * will be capable.
*
- * The setting to prefer plain-old Java is ignored for generated
+ * The setting to prefer plain-old Java is ignored for any remaining
generated
* classes not marked as plain-old Java capable.
*/
public class ClassBuilder {
- public static final String SAVE_CODE_OPTION = CodeCompiler.COMPILE_BASE
+ ".save_source";
public static final String CODE_DIR_OPTION = CodeCompiler.COMPILE_BASE +
".code_dir";
private final DrillConfig config;
private final OptionManager options;
- private final boolean saveCode;
private final File codeDir;
public ClassBuilder(DrillConfig config, OptionManager optionManager) {
this.config = config;
options = optionManager;
-// The option to save code is a boot-time option because
-// it is used selectively during debugging, but can cause
-// excessive I/O in a running server if used to save all code.
+// Code can be saved per-class to enable debugging.
+// Just mark the code generator as to be persisted,
+// point your debugger to the directory set below, and you
--- End diff --
Thanks. The key thing to remember here is that the generated code does not
exist until the code generator runs, so it is somewhat hard to set a breakpoint
ahead of time given the current structure.
You are right that we can *add* another feature that causes the code to
reuse class names so that we can set breakpoints inside the generated code. I
worked around this in my sort performance stuff by creating my own copy of the
code which I then hand modified to try out various changes. That was a quick
way to avoid the name issue and to try changes without having to muck with the
code generator just to do a prototype.
Do you feel we need to add the consistent-class-name feature in this PR, or
can that be a refinement in a later PR?
And, I agree we should document usage as a way to encourage folks to try it
and help us figure out what else we can improve.
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816476#comment-15816476
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95469122
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/ClassBuilder.java ---
@@ -141,7 +142,9 @@ public ClassBuilder(DrillConfig config, OptionManager
optionManager) {
// A key advantage of this method is that the code can be
// saved and debugged, if needed.
-saveCode(code, name);
+if (cg.persistCode()) {
--- End diff --
Method names changed to `saveCodeForDebugging` and `isCodeToBeSaved`. More
of a mouthful, but hopefully this will be clearer -- also clearer that code is
saved only for the purpose of debugging (not, for example, as a code cache that
spans Drillbit runs, etc.) I'd kind of hoped the Javadoc would explain all
that...
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816477#comment-15816477
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95471607
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/CodeCompiler.java ---
@@ -41,12 +39,87 @@
*/
public class CodeCompiler {
+ private static final org.slf4j.Logger logger =
org.slf4j.LoggerFactory.getLogger(CodeCompiler.class);
+
+ /**
+ * Abstracts out the details of compiling code using the two available
+ * mechanisms. Allows this mechanism to be unit tested separately from
+ * the code cache.
+ */
+
+ public static class CodeGenCompiler {
+private final ClassTransformer transformer;
+private final ClassBuilder classBuilder;
+
+public CodeGenCompiler(final DrillConfig config, final OptionManager
optionManager) {
+ transformer = new ClassTransformer(config, optionManager);
+ classBuilder = new ClassBuilder(config, optionManager);
+}
+
+/**
+ * Compile the code already generated by the code generator.
+ *
+ * @param cg the code generator for the class
+ * @return the compiled class
+ * @throws Exception if anything goes wrong
+ */
+
+public Class compile(final CodeGenerator cg) throws Exception {
+ if (cg.isPlainOldJava()) {
--- End diff --
Done. Trace logging will identify if the class was found in the code cache,
or compile via plain-Java or byte code manipulation. Also logged the compiler
selection and debug code options (which are set statically). This should
provide most information needed to understand a run.
Also added the requested information about a plain-Java compilation: the
byte code size and elapsed time. Revised both log messages to include class
name to provide some context for the compilation messages.
The missing information is whether a particular class was compiled with
Janino or JDK.
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816479#comment-15816479
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95472935
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/exec/physical/impl/TestConvertFunctions.java
---
@@ -76,6 +75,22 @@
String textFileContent;
+ @BeforeClass
+ public static void setup( ) {
+// Tests here rely on the byte-code merge approach to code
+// generation and will fail if using plain-old Java.
+// Actually, some queries succeed with plain-old Java that
+// fail with scalar replacement, but the tests check for the
+// scalar replacement failure and, not finding it, fail the
+// test.
+//
+// The setting here forces byte-code merge even if the
+// config file asks for plain-old Java.
+// TODO: Fix the tests to handle both cases.
+
+System.setProperty("drill.compile.prefer_plain_java", "false");
--- End diff --
Fixed as above.
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816478#comment-15816478
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95472493
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/exec/compile/TestClassTransformation.java
---
@@ -44,6 +44,9 @@
@BeforeClass
public static void beforeTestClassTransformation() throws Exception {
+// Tests here require the byte-code merge technique and are meaningless
+// if the plain-old Java technique is selected.
+System.setProperty("drill.compile.prefer_plain_java", "false");
--- End diff --
You are right. Replaced the name with the constant defined in
`CodeCompiler` as I should have done in the first place.
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816480#comment-15816480
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95479214
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/ClassBuilder.java ---
@@ -64,14 +67,12 @@
* local variables. Have fun!
*
*
- * Note: not all generated code is ready to be compiled as plain-old
- * Java. Some classes omit from the template the proper throws
- * declarations. Other minor problems may also crop up. All are easy
- * to fix. Once you've done so, add the following to mark that you've
- * done the clean-up:
- * cg.plainOldJavaCapable(true); // Class supports plain-old Java
+ * Most generated classes have been upgraded to support Plain-old Java
+ * compilation. Once this work is complete, the calls to
+ * plainOldJavaCapable can be removed as all generated classes
+ * will be capable.
*
- * The setting to prefer plain-old Java is ignored for generated
+ * The setting to prefer plain-old Java is ignored for any remaining
generated
--- End diff --
Since I had to rename other method; went ahead and changed references to
"plain-old Java" to just "plain Java."
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5172) Display elapsed time for queries in the UI
[
https://issues.apache.org/jira/browse/DRILL-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816427#comment-15816427
]
ASF GitHub Bot commented on DRILL-5172:
---
Github user kkhatua commented on a diff in the pull request:
https://github.com/apache/drill/pull/719#discussion_r95475935
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/profile/ProfileResources.java
---
@@ -105,6 +109,25 @@ public String getTime() {
return format.format(time);
}
+public long getStartTime() {
+ return startTime;
+}
+
+public long getEndTime() {
+ return endTime;
+}
+
+public String getDuration() {
--- End diff --
Done. This is a much simpler and cleaner solution. Thank you,
@arina-ielchiieva !
> Display elapsed time for queries in the UI
> --
>
> Key: DRILL-5172
> URL: https://issues.apache.org/jira/browse/DRILL-5172
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.9.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Minor
> Fix For: 1.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, the Web UI does not display the runtime for a query either in the
> list of queries or the query profile page itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5172) Display elapsed time for queries in the UI
[
https://issues.apache.org/jira/browse/DRILL-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816352#comment-15816352
]
ASF GitHub Bot commented on DRILL-5172:
---
Github user kkhatua commented on a diff in the pull request:
https://github.com/apache/drill/pull/719#discussion_r95470389
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/profile/ProfileResources.java
---
@@ -105,6 +109,25 @@ public String getTime() {
return format.format(time);
}
+public long getStartTime() {
+ return startTime;
+}
+
+public long getEndTime() {
+ return endTime;
+}
+
+public String getDuration() {
--- End diff --
That could be one way to work around it. It would be good to have the
human-readable formatting done through only one static method. I'm still trying
to familiarize myself with the way these classes and the freemarker templates
interact, so let me see if I can do with a wrapper. :)
> Display elapsed time for queries in the UI
> --
>
> Key: DRILL-5172
> URL: https://issues.apache.org/jira/browse/DRILL-5172
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.9.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Minor
> Fix For: 1.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, the Web UI does not display the runtime for a query either in the
> list of queries or the query profile page itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5172) Display elapsed time for queries in the UI
[
https://issues.apache.org/jira/browse/DRILL-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816338#comment-15816338
]
ASF GitHub Bot commented on DRILL-5172:
---
Github user kkhatua commented on a diff in the pull request:
https://github.com/apache/drill/pull/719#discussion_r95469066
--- Diff:
protocol/src/main/java/org/apache/drill/exec/proto/UserBitShared.java ---
@@ -13595,6 +13597,17 @@ public long getEnd() {
return end_;
}
+public String getDuration() {
--- End diff --
The ProfileInfo class is actually where the change was made to retrieve the
value from the model. We don't create any duration field, as it is computed
based on the other 2 fields (start,end) and simply provide a getter for that.
However, the ProfileInfo class is used only by the profiles listing freemarker
template (list.ftl).
For the individual query profile's template (profile.ftl), the model from
which we retrieve the duration value is auto-generated by the protobuf, making
this a lot more complicated to implement. Hence, we took the JavaScript
approach.
I'll probably refine it to strictly follow the MVC model when I'm
attempting a fix for DRILL-5190
https://issues.apache.org/jira/browse/DRILL-5190 [Display planning time for a
query in its profile page ] , since that would require me to modify the
protobuf.
> Display elapsed time for queries in the UI
> --
>
> Key: DRILL-5172
> URL: https://issues.apache.org/jira/browse/DRILL-5172
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.9.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Minor
> Fix For: 1.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, the Web UI does not display the runtime for a query either in the
> list of queries or the query profile page itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-5190) Display planning time for a query in its profile page
Kunal Khatua created DRILL-5190: --- Summary: Display planning time for a query in its profile page Key: DRILL-5190 URL: https://issues.apache.org/jira/browse/DRILL-5190 Project: Apache Drill Issue Type: Bug Components: Web Server Affects Versions: 1.9.0 Reporter: Kunal Khatua Currently, the Web UI does not display the time spent in planning for a query in its profile page. The estimate needs to be done by seeing how late did the earliest major fragment start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816244#comment-15816244
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95461369
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/ClassBuilder.java ---
@@ -64,36 +67,33 @@
* local variables. Have fun!
*
*
- * Note: not all generated code is ready to be compiled as plain-old
- * Java. Some classes omit from the template the proper throws
- * declarations. Other minor problems may also crop up. All are easy
- * to fix. Once you've done so, add the following to mark that you've
- * done the clean-up:
- * cg.plainOldJavaCapable(true); // Class supports plain-old Java
+ * Most generated classes have been upgraded to support Plain-old Java
+ * compilation. Once this work is complete, the calls to
+ * plainOldJavaCapable can be removed as all generated classes
+ * will be capable.
*
- * The setting to prefer plain-old Java is ignored for generated
+ * The setting to prefer plain-old Java is ignored for any remaining
generated
* classes not marked as plain-old Java capable.
*/
public class ClassBuilder {
- public static final String SAVE_CODE_OPTION = CodeCompiler.COMPILE_BASE
+ ".save_source";
public static final String CODE_DIR_OPTION = CodeCompiler.COMPILE_BASE +
".code_dir";
private final DrillConfig config;
private final OptionManager options;
- private final boolean saveCode;
private final File codeDir;
public ClassBuilder(DrillConfig config, OptionManager optionManager) {
this.config = config;
options = optionManager;
-// The option to save code is a boot-time option because
-// it is used selectively during debugging, but can cause
-// excessive I/O in a running server if used to save all code.
+// Code can be saved per-class to enable debugging.
+// Just mark the code generator as to be persisted,
+// point your debugger to the directory set below, and you
--- End diff --
What we talked about probably is slightly different. What you mean is to
step into the generated code, without setting a breaking point in it. What I
mean is first run the query and have the code generated, then I setup some
breakpoint in the code generated, re-run the query and start debugs. In such
cases, we need make sure the two runs of query get the same class names,
otherwise the breakpoint will not be effective.
Either way, it would be good to doc the typical ways of using the generated
code in debug mode.
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816228#comment-15816228
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95459877
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/CodeCompiler.java ---
@@ -41,12 +39,87 @@
*/
public class CodeCompiler {
+ private static final org.slf4j.Logger logger =
org.slf4j.LoggerFactory.getLogger(CodeCompiler.class);
+
+ /**
+ * Abstracts out the details of compiling code using the two available
+ * mechanisms. Allows this mechanism to be unit tested separately from
+ * the code cache.
+ */
+
+ public static class CodeGenCompiler {
+private final ClassTransformer transformer;
+private final ClassBuilder classBuilder;
+
+public CodeGenCompiler(final DrillConfig config, final OptionManager
optionManager) {
+ transformer = new ClassTransformer(config, optionManager);
+ classBuilder = new ClassBuilder(config, optionManager);
+}
+
+/**
+ * Compile the code already generated by the code generator.
+ *
+ * @param cg the code generator for the class
+ * @return the compiled class
+ * @throws Exception if anything goes wrong
+ */
+
+public Class compile(final CodeGenerator cg) throws Exception {
+ if (cg.isPlainOldJava()) {
--- End diff --
Since we now have to modes for runtime code generation across almost all
Drill operators (plain-old vs bytecode transformer), is there a way to check
which mode is used for each operator in a query? It would be nice to include
such information in log, to help analyze a potential issue (whether there is a
bug in the bytecode transformer, or plain-old style class).
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815997#comment-15815997
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user jinfengni commented on the issue:
https://github.com/apache/drill/pull/716
In the current code generator, we log both the source code and the size of
source / byte code, the time spent on compiling, and the complier (Janino vs
JDK) at debug level. It's probably debatable to log the source code, but the
other information is quite useful for analyzing customer issue. In the
plain-old style generator, seems we do not put those information in debug log.
For now, the patch is not enabled. But in the future, if we are going to use
this new code generator in production, we had better log more information(
either in the log, or in operator profile), as that will help improve service
workload.
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-5189) There's no documentation for the typeof() function
Chris Westin created DRILL-5189: --- Summary: There's no documentation for the typeof() function Key: DRILL-5189 URL: https://issues.apache.org/jira/browse/DRILL-5189 Project: Apache Drill Issue Type: Bug Components: Documentation Reporter: Chris Westin I looked through the documentation at https://drill.apache.org/docs/ under SQL Reference > SQL Functions > ... and could not find any reference to typeof(). Google searches only turned up a reference to DRILL-4204. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815977#comment-15815977
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95442410
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/exec/compile/TestClassTransformation.java
---
@@ -44,6 +44,9 @@
@BeforeClass
public static void beforeTestClassTransformation() throws Exception {
+// Tests here require the byte-code merge technique and are meaningless
+// if the plain-old Java technique is selected.
+System.setProperty("drill.compile.prefer_plain_java", "false");
--- End diff --
Any comment regarding this one? I thought the name of the options has a
typo?
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5116) Enable generated code debugging in each Drill operator
[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815975#comment-15815975
]
ASF GitHub Bot commented on DRILL-5116:
---
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95442239
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/ClassBuilder.java ---
@@ -141,7 +142,9 @@ public ClassBuilder(DrillConfig config, OptionManager
optionManager) {
// A key advantage of this method is that the code can be
// saved and debugged, if needed.
-saveCode(code, name);
+if (cg.persistCode()) {
--- End diff --
Sounds to me that `persistCode(boolean)` is to set the persist boolean flag
in code generator if it's allowed, while `persistCode()` is to check if the
boolean flag is turned on or not. In such case, can we call the former as
`setPersistMode(boolean)`, and call the later as `isPersistable`?
> Enable generated code debugging in each Drill operator
> --
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5172) Display elapsed time for queries in the UI
[
https://issues.apache.org/jira/browse/DRILL-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815902#comment-15815902
]
ASF GitHub Bot commented on DRILL-5172:
---
Github user arina-ielchiieva commented on a diff in the pull request:
https://github.com/apache/drill/pull/719#discussion_r95436174
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/profile/ProfileResources.java
---
@@ -105,6 +109,25 @@ public String getTime() {
return format.format(time);
}
+public long getStartTime() {
+ return startTime;
+}
+
+public long getEndTime() {
+ return endTime;
+}
+
+public String getDuration() {
--- End diff --
How about we create wrapper class around `QueryProfile` (ex:
`QueryProfileWrapper`) which will contain `getDuration` method along with
needed `QueryProfile` methods. Logic for converting two long values (start and
end) into human-readable format will be factored out into static method in
`ProfileResources` (ex: `convertDurationIntoString(long start, long end)`).
`QueryProfileWrapper` and `ProfileResources` will call this utility method from
their `getDuration` methods.
> Display elapsed time for queries in the UI
> --
>
> Key: DRILL-5172
> URL: https://issues.apache.org/jira/browse/DRILL-5172
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.9.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Minor
> Fix For: 1.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, the Web UI does not display the runtime for a query either in the
> list of queries or the query profile page itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5172) Display elapsed time for queries in the UI
[
https://issues.apache.org/jira/browse/DRILL-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815854#comment-15815854
]
ASF GitHub Bot commented on DRILL-5172:
---
Github user kkhatua commented on a diff in the pull request:
https://github.com/apache/drill/pull/719#discussion_r95432224
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/profile/ProfileResources.java
---
@@ -105,6 +109,25 @@ public String getTime() {
return format.format(time);
}
+public long getStartTime() {
+ return startTime;
+}
+
+public long getEndTime() {
+ return endTime;
+}
+
+public String getDuration() {
--- End diff --
The logic in this Java class provides the duration for the listing
generated in the profile listing Freemarker file (list.ftl). For the actual
query profile page, this gets trickier, since the freemarker template refers to
methods from the auto-generated UserBitShared class in the protocol package.
> Display elapsed time for queries in the UI
> --
>
> Key: DRILL-5172
> URL: https://issues.apache.org/jira/browse/DRILL-5172
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.9.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Minor
> Fix For: 1.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, the Web UI does not display the runtime for a query either in the
> list of queries or the query profile page itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-5152) Enhance the mock data source: better data, SQL access
[
https://issues.apache.org/jira/browse/DRILL-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sorabh Hamirwasia updated DRILL-5152:
-
Labels: ready-to-commit (was: )
> Enhance the mock data source: better data, SQL access
> -
>
> Key: DRILL-5152
> URL: https://issues.apache.org/jira/browse/DRILL-5152
> Project: Apache Drill
> Issue Type: Improvement
> Components: Tools, Build & Test
>Affects Versions: 1.9.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
> Labels: ready-to-commit
>
> Drill provides a mock data storage engine that generates random data. The
> mock engine is used in some older unit tests that need a volume of data, but
> that are not too particular about the details of the data.
> The mock data source continues to have use even for modern tests. For
> example, the work in the external storage batch requires tests with varying
> amounts of data, but the exact form of the data is not important, just the
> quantity. For example, if we want to ensure that spilling happens at various
> trigger points, we need to read the right amount of data for that trigger.
> The existing mock data source has two limitations:
> 1. It generates only "black/white" (alternating) values, which is awkward for
> use in sorting.
> 2. The mock generator is accessible only from a physical plan, but not from
> SQL queries.
> This enhancement proposes to fix both limitations:
> 1. Generate a uniform, randomly distributed set of values.
> 2. Provide an encoding that lets a SQL query specify the data to be generated.
> Example SQL query:
> {code}
> SELECT id_i, name_s50 FROM `mock`.employee_10K;
> {code}
> The above says to generate two fields: INTEGER (the "_i" suffix) and
> VARCHAR(50) (the "_s50") suffix; and to generate 10,000 rows (the "_10K"
> suffix on the table.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3562) Query fails when using flatten on JSON data where some documents have an empty array
[
https://issues.apache.org/jira/browse/DRILL-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serhii Harnyk updated DRILL-3562:
-
Labels: (was: ready-to-commit)
> Query fails when using flatten on JSON data where some documents have an
> empty array
>
>
> Key: DRILL-3562
> URL: https://issues.apache.org/jira/browse/DRILL-3562
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JSON
>Affects Versions: 1.1.0
>Reporter: Philip Deegan
>Assignee: Serhii Harnyk
> Fix For: Future
>
>
> Drill query fails when using flatten when some records contain an empty array
> {noformat}
> SELECT COUNT(*) FROM (SELECT FLATTEN(t.a.b.c) AS c FROM dfs.`flat.json` t)
> flat WHERE flat.c.d.e = 'f' limit 1;
> {noformat}
> Succeeds on
> { "a": { "b": { "c": [ { "d": { "e": "f" } } ] } } }
> Fails on
> { "a": { "b": { "c": [] } } }
> Error
> {noformat}
> Error: SYSTEM ERROR: ClassCastException: Cannot cast
> org.apache.drill.exec.vector.NullableIntVector to
> org.apache.drill.exec.vector.complex.RepeatedValueVector
> {noformat}
> Is it possible to ignore the empty arrays, or do they need to be populated
> with dummy data?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5172) Display elapsed time for queries in the UI
[
https://issues.apache.org/jira/browse/DRILL-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815539#comment-15815539
]
ASF GitHub Bot commented on DRILL-5172:
---
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/719#discussion_r95411447
--- Diff:
protocol/src/main/java/org/apache/drill/exec/proto/UserBitShared.java ---
@@ -13595,6 +13597,17 @@ public long getEnd() {
return end_;
}
+public String getDuration() {
--- End diff --
Actually, the right place to do this work is in the Java code that creates
the "model" that we pass to Freemarker. (Yeah, it is kind of complicated.)
Freemarker uses the classic MVC model. The template is the view. Java
builds the model. (Let's ignore the controller for now.)
For an example, look in `ProfileResources.java`, which is in this PR. Look
at the `ProfileInfo` class. Here we gather up the bits of information we want
to display on the web page. Any calcs needed to prepare the data are done here.
Then, Freemarker simply pulls out the pre-created data using the getter methods.
So, the `ProfileInfo` class could be extended to have, say, the raw
duration in ms along with methods to return the computed values:
`getDisplayDuration()` and `getDurationUnits()`.
> Display elapsed time for queries in the UI
> --
>
> Key: DRILL-5172
> URL: https://issues.apache.org/jira/browse/DRILL-5172
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.9.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Minor
> Fix For: 1.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, the Web UI does not display the runtime for a query either in the
> list of queries or the query profile page itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-5188) TPC-DS query16 fails - IllegalArgumentException: Target must be less than target count
[
https://issues.apache.org/jira/browse/DRILL-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814810#comment-15814810
]
Khurram Faraaz commented on DRILL-5188:
---
Yes, quite likely. CALCITE-816 was fixed in release Calcite 1.6.0.
I will keep this JIRA open until Drill is in sync with latest changes from
Calcite.
> TPC-DS query16 fails - IllegalArgumentException: Target must be less than
> target count
> --
>
> Key: DRILL-5188
> URL: https://issues.apache.org/jira/browse/DRILL-5188
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.10.0
> Environment: 4 node cluster
>Reporter: Khurram Faraaz
>
> TPC-DS query 16 fails with below Exception. Query 32, Query 92, query 95 also
> fail due to same Exception, on Drill 1.10.0 (commit ID: bbcf4b76) against SF1
> data.
> Details from drillbit.log and stack trace.
> {noformat}
> 2017-01-10 11:42:54,769 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - Query text for query id
> 278b3740-fa7b-0f27-5c42-92f2f63f7f3d: SELECT
> Count(DISTINCT cs_order_number) AS `order count` ,
> Sum(cs_ext_ship_cost) AS `total shipping cost` ,
> Sum(cs_net_profit) AS `total net profit`
> FROM catalog_sales cs1 ,
> date_dim ,
> customer_address ,
> call_center
> WHEREd_date BETWEEN '2002-3-01' AND (
> Cast('2002-3-01' AS DATE) + INTERVAL '60' day)
> AND cs1.cs_ship_date_sk = d_date_sk
> AND cs1.cs_ship_addr_sk = ca_address_sk
> AND ca_state = 'IA'
> AND cs1.cs_call_center_sk = cc_call_center_sk
> AND cc_county IN ('Williamson County',
> 'Williamson County',
> 'Williamson County',
> 'Williamson County',
> 'Williamson County' )
> AND EXISTS
> (
> SELECT *
> FROM catalog_sales cs2
> WHERE cs1.cs_order_number = cs2.cs_order_number
> ANDcs1.cs_warehouse_sk <> cs2.cs_warehouse_sk)
> AND NOT EXISTS
> (
> SELECT *
> FROM catalog_returns cr1
> WHERE cs1.cs_order_number = cr1.cr_order_number)
> ORDER BY count(DISTINCT cs_order_number)
> LIMIT 100
> 2017-01-10 11:42:54,887 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,888 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,895 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,895 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,902 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,903 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,908 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,909 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,919 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,920 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,946 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] ERROR
> o.a.drill.exec.work.foreman.Foreman - SYSTEM ERROR: IllegalArgumentException:
> Target must be less than target count, 3
> [Error Id: 61befda9-3479-48a4-a6ff-181703aea1b7 on centos-01.qa.lab:31010]
> org.apache.drill.common.exceptions.UserException: SYSTEM ERROR:
> IllegalArgumentException: Target must be less than target count, 3
> [Error Id: 61befda9-3479-48a4-a6ff-181703aea1b7 on centos-01.qa.lab:31010]
> at
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:544)
> ~[drill-common-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:824)
> [drill-java-exec-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:944)
> [drill-java-exec-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
>
[jira] [Commented] (DRILL-5188) TPC-DS query16 fails - IllegalArgumentException: Target must be less than target count
[
https://issues.apache.org/jira/browse/DRILL-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814794#comment-15814794
]
Arina Ielchiieva commented on DRILL-5188:
-
Issue might come from Calcite -
https://issues.apache.org/jira/browse/CALCITE-709
https://issues.apache.org/jira/browse/CALCITE-816
> TPC-DS query16 fails - IllegalArgumentException: Target must be less than
> target count
> --
>
> Key: DRILL-5188
> URL: https://issues.apache.org/jira/browse/DRILL-5188
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.10.0
> Environment: 4 node cluster
>Reporter: Khurram Faraaz
>
> TPC-DS query 16 fails with below Exception. Query 32, Query 92, query 95 also
> fail due to same Exception, on Drill 1.10.0 (commit ID: bbcf4b76) against SF1
> data.
> Details from drillbit.log and stack trace.
> {noformat}
> 2017-01-10 11:42:54,769 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - Query text for query id
> 278b3740-fa7b-0f27-5c42-92f2f63f7f3d: SELECT
> Count(DISTINCT cs_order_number) AS `order count` ,
> Sum(cs_ext_ship_cost) AS `total shipping cost` ,
> Sum(cs_net_profit) AS `total net profit`
> FROM catalog_sales cs1 ,
> date_dim ,
> customer_address ,
> call_center
> WHEREd_date BETWEEN '2002-3-01' AND (
> Cast('2002-3-01' AS DATE) + INTERVAL '60' day)
> AND cs1.cs_ship_date_sk = d_date_sk
> AND cs1.cs_ship_addr_sk = ca_address_sk
> AND ca_state = 'IA'
> AND cs1.cs_call_center_sk = cc_call_center_sk
> AND cc_county IN ('Williamson County',
> 'Williamson County',
> 'Williamson County',
> 'Williamson County',
> 'Williamson County' )
> AND EXISTS
> (
> SELECT *
> FROM catalog_sales cs2
> WHERE cs1.cs_order_number = cs2.cs_order_number
> ANDcs1.cs_warehouse_sk <> cs2.cs_warehouse_sk)
> AND NOT EXISTS
> (
> SELECT *
> FROM catalog_returns cr1
> WHERE cs1.cs_order_number = cr1.cr_order_number)
> ORDER BY count(DISTINCT cs_order_number)
> LIMIT 100
> 2017-01-10 11:42:54,887 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,888 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,895 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,895 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,902 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,903 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,908 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,909 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,919 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,920 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
> o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
> numFiles: 1
> 2017-01-10 11:42:54,946 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] ERROR
> o.a.drill.exec.work.foreman.Foreman - SYSTEM ERROR: IllegalArgumentException:
> Target must be less than target count, 3
> [Error Id: 61befda9-3479-48a4-a6ff-181703aea1b7 on centos-01.qa.lab:31010]
> org.apache.drill.common.exceptions.UserException: SYSTEM ERROR:
> IllegalArgumentException: Target must be less than target count, 3
> [Error Id: 61befda9-3479-48a4-a6ff-181703aea1b7 on centos-01.qa.lab:31010]
> at
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:544)
> ~[drill-common-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:824)
> [drill-java-exec-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:944)
> [drill-java-exec-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
> at
[jira] [Created] (DRILL-5188) TPC-DS query16 fails - IllegalArgumentException: Target must be less than target count
Khurram Faraaz created DRILL-5188:
-
Summary: TPC-DS query16 fails - IllegalArgumentException: Target
must be less than target count
Key: DRILL-5188
URL: https://issues.apache.org/jira/browse/DRILL-5188
Project: Apache Drill
Issue Type: Bug
Components: Execution - Flow
Affects Versions: 1.10.0
Environment: 4 node cluster
Reporter: Khurram Faraaz
TPC-DS query 16 fails with below Exception. Query 32, Query 92, query 95 also
fail due to same Exception, on Drill 1.10.0 (commit ID: bbcf4b76) against SF1
data.
Details from drillbit.log and stack trace.
{noformat}
2017-01-10 11:42:54,769 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.drill.exec.work.foreman.Foreman - Query text for query id
278b3740-fa7b-0f27-5c42-92f2f63f7f3d: SELECT
Count(DISTINCT cs_order_number) AS `order count` ,
Sum(cs_ext_ship_cost) AS `total shipping cost` ,
Sum(cs_net_profit) AS `total net profit`
FROM catalog_sales cs1 ,
date_dim ,
customer_address ,
call_center
WHEREd_date BETWEEN '2002-3-01' AND (
Cast('2002-3-01' AS DATE) + INTERVAL '60' day)
AND cs1.cs_ship_date_sk = d_date_sk
AND cs1.cs_ship_addr_sk = ca_address_sk
AND ca_state = 'IA'
AND cs1.cs_call_center_sk = cc_call_center_sk
AND cc_county IN ('Williamson County',
'Williamson County',
'Williamson County',
'Williamson County',
'Williamson County' )
AND EXISTS
(
SELECT *
FROM catalog_sales cs2
WHERE cs1.cs_order_number = cs2.cs_order_number
ANDcs1.cs_warehouse_sk <> cs2.cs_warehouse_sk)
AND NOT EXISTS
(
SELECT *
FROM catalog_returns cr1
WHERE cs1.cs_order_number = cr1.cr_order_number)
ORDER BY count(DISTINCT cs_order_number)
LIMIT 100
2017-01-10 11:42:54,887 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,888 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,895 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,895 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,902 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,903 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,908 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,909 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,919 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,920 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] INFO
o.a.d.exec.store.dfs.FileSelection - FileSelection.getStatuses() took 0 ms,
numFiles: 1
2017-01-10 11:42:54,946 [278b3740-fa7b-0f27-5c42-92f2f63f7f3d:foreman] ERROR
o.a.drill.exec.work.foreman.Foreman - SYSTEM ERROR: IllegalArgumentException:
Target must be less than target count, 3
[Error Id: 61befda9-3479-48a4-a6ff-181703aea1b7 on centos-01.qa.lab:31010]
org.apache.drill.common.exceptions.UserException: SYSTEM ERROR:
IllegalArgumentException: Target must be less than target count, 3
[Error Id: 61befda9-3479-48a4-a6ff-181703aea1b7 on centos-01.qa.lab:31010]
at
org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:544)
~[drill-common-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:824)
[drill-java-exec-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:944)
[drill-java-exec-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:281)
[drill-java-exec-1.10.0-SNAPSHOT.jar:1.10.0-SNAPSHOT]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: org.apache.drill.exec.work.foreman.ForemanException: Unexpected
exception during fragment initialization: Target must be less than target
count, 3
[jira] [Commented] (DRILL-5172) Display elapsed time for queries in the UI
[
https://issues.apache.org/jira/browse/DRILL-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814703#comment-15814703
]
ASF GitHub Bot commented on DRILL-5172:
---
Github user arina-ielchiieva commented on a diff in the pull request:
https://github.com/apache/drill/pull/719#discussion_r95344665
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/profile/ProfileResources.java
---
@@ -105,6 +109,25 @@ public String getTime() {
return format.format(time);
}
+public long getStartTime() {
+ return startTime;
+}
+
+public long getEndTime() {
+ return endTime;
+}
+
+public String getDuration() {
--- End diff --
It seems we have similar logic here and in freemarker template for
duration. May it can be removed in one of them?
> Display elapsed time for queries in the UI
> --
>
> Key: DRILL-5172
> URL: https://issues.apache.org/jira/browse/DRILL-5172
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.9.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Minor
> Fix For: 1.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, the Web UI does not display the runtime for a query either in the
> list of queries or the query profile page itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-5187) TPC-DS query 72 takes 32 minutes to complete
[ https://issues.apache.org/jira/browse/DRILL-5187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Khurram Faraaz updated DRILL-5187: -- Attachment: tpcds_query72_profile.png query72_JSON_profile.txt query72_drillbit.log quert72_query_plan.txt > TPC-DS query 72 takes 32 minutes to complete > > > Key: DRILL-5187 > URL: https://issues.apache.org/jira/browse/DRILL-5187 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Affects Versions: 1.10.0 > Environment: 4 node cluster >Reporter: Khurram Faraaz >Priority: Critical > Attachments: quert72_query_plan.txt, query72_JSON_profile.txt, > query72_drillbit.log, tpcds_query72_profile.png > > > TPC-DS query takes close to 32 minutes to complete execution on a 4 node > CentOS cluster, on Drill 1.10.0 against SF1 data. > Attached here are, > - drillbit.log (has only query 72 information) > - JSON profile for query 72 > - screen shot of fragment information from profiles tab on UI > > HASH_JOIN operator takes 21minutes (fragment : 04-xx-53). > HASH_JOIN operator seems to be taking longer, it can be verified by looking > at the profile information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-5187) TPC-DS query 72 takes 32 minutes to complete
[ https://issues.apache.org/jira/browse/DRILL-5187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Khurram Faraaz updated DRILL-5187: -- Description: TPC-DS query takes close to 32 minutes to complete execution on a 4 node CentOS cluster, on Drill 1.10.0 against SF1 data. Attached here are, - query plan for query 72 - drillbit.log (has only query 72 information) - JSON profile for query 72 - screen shot of fragment information from profiles tab on UI HASH_JOIN operator takes 21minutes (fragment : 04-xx-53). HASH_JOIN operator seems to be taking longer, it can be verified by looking at the profile information. was: TPC-DS query takes close to 32 minutes to complete execution on a 4 node CentOS cluster, on Drill 1.10.0 against SF1 data. Attached here are, - drillbit.log (has only query 72 information) - JSON profile for query 72 - screen shot of fragment information from profiles tab on UI HASH_JOIN operator takes 21minutes (fragment : 04-xx-53). HASH_JOIN operator seems to be taking longer, it can be verified by looking at the profile information. > TPC-DS query 72 takes 32 minutes to complete > > > Key: DRILL-5187 > URL: https://issues.apache.org/jira/browse/DRILL-5187 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Affects Versions: 1.10.0 > Environment: 4 node cluster >Reporter: Khurram Faraaz >Priority: Critical > Attachments: quert72_query_plan.txt, query72_JSON_profile.txt, > query72_drillbit.log, tpcds_query72_profile.png > > > TPC-DS query takes close to 32 minutes to complete execution on a 4 node > CentOS cluster, on Drill 1.10.0 against SF1 data. > Attached here are, > - query plan for query 72 > - drillbit.log (has only query 72 information) > - JSON profile for query 72 > - screen shot of fragment information from profiles tab on UI > > HASH_JOIN operator takes 21minutes (fragment : 04-xx-53). > HASH_JOIN operator seems to be taking longer, it can be verified by looking > at the profile information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5172) Display elapsed time for queries in the UI
[
https://issues.apache.org/jira/browse/DRILL-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814485#comment-15814485
]
ASF GitHub Bot commented on DRILL-5172:
---
Github user kkhatua commented on a diff in the pull request:
https://github.com/apache/drill/pull/719#discussion_r95327930
--- Diff:
protocol/src/main/java/org/apache/drill/exec/proto/UserBitShared.java ---
@@ -13595,6 +13597,17 @@ public long getEnd() {
return end_;
}
+public String getDuration() {
--- End diff --
Removed the logic. We'll do this within the Webpage using Javascript.
> Display elapsed time for queries in the UI
> --
>
> Key: DRILL-5172
> URL: https://issues.apache.org/jira/browse/DRILL-5172
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.9.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Minor
> Fix For: 1.10.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, the Web UI does not display the runtime for a query either in the
> list of queries or the query profile page itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DRILL-4872) NPE from CTAS partitioned by a projected casted null
[ https://issues.apache.org/jira/browse/DRILL-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814374#comment-15814374 ] Arina Ielchiieva edited comment on DRILL-4872 at 1/10/17 8:54 AM: -- Fix is merged into master with commit id 4d4e0c2b23caead69dd4c6c02c07a9800b3c7611 was (Author: arina): Fixed merged into master with commit id 4d4e0c2b23caead69dd4c6c02c07a9800b3c7611 > NPE from CTAS partitioned by a projected casted null > > > Key: DRILL-4872 > URL: https://issues.apache.org/jira/browse/DRILL-4872 > Project: Apache Drill > Issue Type: Bug > Components: Functions - Drill >Affects Versions: 1.7.0 >Reporter: Boaz Ben-Zvi >Assignee: Arina Ielchiieva > Labels: NPE > Fix For: 1.10.0 > > > Extracted from DRILL-3898 : Running the same test case on a smaller table ( > store_sales.dat from TPCDS SF 1) has no space issues, but there is a Null > Pointer Exception from the projection: > Caused by: java.lang.NullPointerException: null > at > org.apache.drill.exec.expr.fn.impl.ByteFunctionHelpers.compare(ByteFunctionHelpers.java:100) > ~[vector-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > at > org.apache.drill.exec.test.generated.ProjectorGen1.doEval(ProjectorTemplate.java:49) > ~[na:na] > at > org.apache.drill.exec.test.generated.ProjectorGen1.projectRecords(ProjectorTemplate.java:62) > ~[na:na] > at > org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.doWork(ProjectRecordBatch.java:199) > ~[drill-java-exec-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > A simplified version of the test case: > 0: jdbc:drill:zk=local> create table dfs.tmp.ttt partition by ( x ) as select > case when columns[8] = '' then cast(null as varchar(10)) else cast(columns[8] > as varchar(10)) end as x FROM > dfs.`/Users/boazben-zvi/data/store_sales/store_sales.dat`; > Error: SYSTEM ERROR: NullPointerException > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-4872) NPE from CTAS partitioned by a projected casted null
[ https://issues.apache.org/jira/browse/DRILL-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814374#comment-15814374 ] Arina Ielchiieva commented on DRILL-4872: - Fixed merged into master with commit id 4d4e0c2b23caead69dd4c6c02c07a9800b3c7611 > NPE from CTAS partitioned by a projected casted null > > > Key: DRILL-4872 > URL: https://issues.apache.org/jira/browse/DRILL-4872 > Project: Apache Drill > Issue Type: Bug > Components: Functions - Drill >Affects Versions: 1.7.0 >Reporter: Boaz Ben-Zvi >Assignee: Arina Ielchiieva > Labels: NPE > Fix For: 1.10.0 > > > Extracted from DRILL-3898 : Running the same test case on a smaller table ( > store_sales.dat from TPCDS SF 1) has no space issues, but there is a Null > Pointer Exception from the projection: > Caused by: java.lang.NullPointerException: null > at > org.apache.drill.exec.expr.fn.impl.ByteFunctionHelpers.compare(ByteFunctionHelpers.java:100) > ~[vector-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > at > org.apache.drill.exec.test.generated.ProjectorGen1.doEval(ProjectorTemplate.java:49) > ~[na:na] > at > org.apache.drill.exec.test.generated.ProjectorGen1.projectRecords(ProjectorTemplate.java:62) > ~[na:na] > at > org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.doWork(ProjectRecordBatch.java:199) > ~[drill-java-exec-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > A simplified version of the test case: > 0: jdbc:drill:zk=local> create table dfs.tmp.ttt partition by ( x ) as select > case when columns[8] = '' then cast(null as varchar(10)) else cast(columns[8] > as varchar(10)) end as x FROM > dfs.`/Users/boazben-zvi/data/store_sales/store_sales.dat`; > Error: SYSTEM ERROR: NullPointerException > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-4872) NPE from CTAS partitioned by a projected casted null
[ https://issues.apache.org/jira/browse/DRILL-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva resolved DRILL-4872. - Resolution: Fixed > NPE from CTAS partitioned by a projected casted null > > > Key: DRILL-4872 > URL: https://issues.apache.org/jira/browse/DRILL-4872 > Project: Apache Drill > Issue Type: Bug > Components: Functions - Drill >Affects Versions: 1.7.0 >Reporter: Boaz Ben-Zvi >Assignee: Arina Ielchiieva > Labels: NPE > Fix For: 1.10.0 > > > Extracted from DRILL-3898 : Running the same test case on a smaller table ( > store_sales.dat from TPCDS SF 1) has no space issues, but there is a Null > Pointer Exception from the projection: > Caused by: java.lang.NullPointerException: null > at > org.apache.drill.exec.expr.fn.impl.ByteFunctionHelpers.compare(ByteFunctionHelpers.java:100) > ~[vector-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > at > org.apache.drill.exec.test.generated.ProjectorGen1.doEval(ProjectorTemplate.java:49) > ~[na:na] > at > org.apache.drill.exec.test.generated.ProjectorGen1.projectRecords(ProjectorTemplate.java:62) > ~[na:na] > at > org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.doWork(ProjectRecordBatch.java:199) > ~[drill-java-exec-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > A simplified version of the test case: > 0: jdbc:drill:zk=local> create table dfs.tmp.ttt partition by ( x ) as select > case when columns[8] = '' then cast(null as varchar(10)) else cast(columns[8] > as varchar(10)) end as x FROM > dfs.`/Users/boazben-zvi/data/store_sales/store_sales.dat`; > Error: SYSTEM ERROR: NullPointerException > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5186) IS NULL not Working for where condition on INTEGER Column where it has no rows to return
[ https://issues.apache.org/jira/browse/DRILL-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814371#comment-15814371 ] Khurram Faraaz commented on DRILL-5186: --- Can you please share the stack trace from drillbit.log ? Is the data in parquet format or text ?, or is the query run over a table in Oracle database ? > IS NULL not Working for where condition on INTEGER Column where it has no > rows to return > > > Key: DRILL-5186 > URL: https://issues.apache.org/jira/browse/DRILL-5186 > Project: Apache Drill > Issue Type: Bug > Components: Query Planning & Optimization >Affects Versions: 1.8.0 >Reporter: Ravan > > Query1: (Working) > select * from orcl.DEV.emp where ename is null > O/P: No Results Found > Query2: (Working) > select * from orcl.DEV.emp where comm is null > Query3: (Getting below Exception) > select * from orcl.DEV.emp where empno is null > Getting below exception:- > Query Failed: An Error Occurred > org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR: > NullPointerException > No use even after altering as > alter session set `drill.exec.functions.cast_empty_string_to_null` = true; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-4872) NPE from CTAS partitioned by a projected casted null
[ https://issues.apache.org/jira/browse/DRILL-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-4872: Fix Version/s: (was: Future) 1.10.0 > NPE from CTAS partitioned by a projected casted null > > > Key: DRILL-4872 > URL: https://issues.apache.org/jira/browse/DRILL-4872 > Project: Apache Drill > Issue Type: Bug > Components: Functions - Drill >Affects Versions: 1.7.0 >Reporter: Boaz Ben-Zvi > Labels: NPE > Fix For: 1.10.0 > > > Extracted from DRILL-3898 : Running the same test case on a smaller table ( > store_sales.dat from TPCDS SF 1) has no space issues, but there is a Null > Pointer Exception from the projection: > Caused by: java.lang.NullPointerException: null > at > org.apache.drill.exec.expr.fn.impl.ByteFunctionHelpers.compare(ByteFunctionHelpers.java:100) > ~[vector-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > at > org.apache.drill.exec.test.generated.ProjectorGen1.doEval(ProjectorTemplate.java:49) > ~[na:na] > at > org.apache.drill.exec.test.generated.ProjectorGen1.projectRecords(ProjectorTemplate.java:62) > ~[na:na] > at > org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.doWork(ProjectRecordBatch.java:199) > ~[drill-java-exec-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > A simplified version of the test case: > 0: jdbc:drill:zk=local> create table dfs.tmp.ttt partition by ( x ) as select > case when columns[8] = '' then cast(null as varchar(10)) else cast(columns[8] > as varchar(10)) end as x FROM > dfs.`/Users/boazben-zvi/data/store_sales/store_sales.dat`; > Error: SYSTEM ERROR: NullPointerException > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-4872) NPE from CTAS partitioned by a projected casted null
[ https://issues.apache.org/jira/browse/DRILL-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva reassigned DRILL-4872: --- Assignee: Arina Ielchiieva > NPE from CTAS partitioned by a projected casted null > > > Key: DRILL-4872 > URL: https://issues.apache.org/jira/browse/DRILL-4872 > Project: Apache Drill > Issue Type: Bug > Components: Functions - Drill >Affects Versions: 1.7.0 >Reporter: Boaz Ben-Zvi >Assignee: Arina Ielchiieva > Labels: NPE > Fix For: 1.10.0 > > > Extracted from DRILL-3898 : Running the same test case on a smaller table ( > store_sales.dat from TPCDS SF 1) has no space issues, but there is a Null > Pointer Exception from the projection: > Caused by: java.lang.NullPointerException: null > at > org.apache.drill.exec.expr.fn.impl.ByteFunctionHelpers.compare(ByteFunctionHelpers.java:100) > ~[vector-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > at > org.apache.drill.exec.test.generated.ProjectorGen1.doEval(ProjectorTemplate.java:49) > ~[na:na] > at > org.apache.drill.exec.test.generated.ProjectorGen1.projectRecords(ProjectorTemplate.java:62) > ~[na:na] > at > org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.doWork(ProjectRecordBatch.java:199) > ~[drill-java-exec-1.8.0-SNAPSHOT.jar:1.8.0-SNAPSHOT] > A simplified version of the test case: > 0: jdbc:drill:zk=local> create table dfs.tmp.ttt partition by ( x ) as select > case when columns[8] = '' then cast(null as varchar(10)) else cast(columns[8] > as varchar(10)) end as x FROM > dfs.`/Users/boazben-zvi/data/store_sales/store_sales.dat`; > Error: SYSTEM ERROR: NullPointerException > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-5039) NPE - CTAS PARTITION BY ()
[
https://issues.apache.org/jira/browse/DRILL-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814297#comment-15814297
]
Arina Ielchiieva commented on DRILL-5039:
-
Merged into master with commit id 4d4e0c2b23caead69dd4c6c02c07a9800b3c7611
> NPE - CTAS PARTITION BY ()
>
>
> Key: DRILL-5039
> URL: https://issues.apache.org/jira/browse/DRILL-5039
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.9.0
>Reporter: Khurram Faraaz
>Assignee: Arina Ielchiieva
>Priority: Critical
> Labels: ready-to-commit
> Fix For: 1.10.0
>
>
> We are seeing an NPE, when CTAS is used with PARTITION BY
> () and all columns are projected in SELECT of CTAS.
> Drill 1.9.0
> git commit ID : db30854
> {noformat}
> 0: jdbc:drill:schema=dfs.tmp> CREATE TABLE dfs.tmp.temp_tbl
> . . . . . . . . . . . . . . > PARTITION BY (col_chr)
> . . . . . . . . . . . . . . > AS
> . . . . . . . . . . . . . . > SELECT col_int, col_chr, col_vrchr1, col_vrchr2
> , col_dt, col_tim, col_tmstmp , col_flt, col_intrvl_yr , col_intrvl_day ,
> col_bln
> . . . . . . . . . . . . . . > FROM typeall_l;
> Error: SYSTEM ERROR: NullPointerException
> Fragment 0:0
> [Error Id: ab6c199e-cb61-42dd-ae22-0090eea22ec5 on centos-01.qa.lab:31010]
> (state=,code=0)
> {noformat}
> {noformat}
> 2016-11-12 19:54:14,901 [27d88c99-a64d-0317-ba3b-d78195cf85cc:frag:0:0] ERROR
> o.a.d.e.w.fragment.FragmentExecutor - SYSTEM ERROR: NullPointerException
> Fragment 0:0
> [Error Id: ab6c199e-cb61-42dd-ae22-0090eea22ec5 on centos-01.qa.lab:31010]
> org.apache.drill.common.exceptions.UserException: SYSTEM ERROR:
> NullPointerException
> Fragment 0:0
> [Error Id: ab6c199e-cb61-42dd-ae22-0090eea22ec5 on centos-01.qa.lab:31010]
> at
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:543)
> ~[drill-common-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:293)
> [drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.cleanup(FragmentExecutor.java:160)
> [drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:262)
> [drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
> [drill-common-1.9.0.jar:1.9.0]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_91]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.drill.exec.expr.fn.impl.ByteFunctionHelpers.compare(ByteFunctionHelpers.java:100)
> ~[vector-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.test.generated.ProjectorGen3.doEval(ProjectorTemplate.java:88)
> ~[na:na]
> at
> org.apache.drill.exec.test.generated.ProjectorGen3.projectRecords(ProjectorTemplate.java:62)
> ~[na:na]
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.doWork(ProjectRecordBatch.java:199)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:93)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:135)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:162)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:119)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:109)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.physical.impl.WriterRecordBatch.innerNext(WriterRecordBatch.java:91)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:162)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:119)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:109)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> ~[drill-java-exec-1.9.0.jar:1.9.0]
> at
>
