[jira] [Resolved] (DRILL-5532) TPCH Query 16 failed when planner.width.max_per_node <10
[
https://issues.apache.org/jira/browse/DRILL-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi resolved DRILL-5532.
Resolution: Cannot Reproduce
> TPCH Query 16 failed when planner.width.max_per_node <10
>
>
> Key: DRILL-5532
> URL: https://issues.apache.org/jira/browse/DRILL-5532
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Affects Versions: 1.11.0
> Environment: 10 node cluster, rhel6.4
>Reporter: Dechang Gu
>Assignee: Volodymyr Vysotskyi
> Attachments:
> pfofile_tpch16_gitid_8412ad4.26dce567-5ec0-8bbf-c099-f2d6307bdeef.sys.drill,
> profile_tpch16_gitid_adbf363.26dce6f3-3d75-e906-bfcb-2c6541ee2ff0.sys.drill
>
>
> When set planner.width.max_per_node < 10 (tried 6, 8, and 9): TPCH query 16
> failed with the following error:
> {code}
> java.sql.SQLException: SYSTEM ERROR: NullPointerException
> Fragment 1:1
> [Error Id: ba4661b4-2ff6-4eff-889c-fc4604a57418 on ucs-node8.perf.lab:31010]
> (java.lang.NullPointerException) null
> org.apache.drill.exec.vector.VarCharVector$Mutator.setSafe():607
> org.apache.drill.exec.vector.NullableVarCharVector$Mutator.setSafe():560
>
> org.apache.drill.exec.test.generated.StreamingAggregatorGen250.outputRecordKeysPrev():525
>
> org.apache.drill.exec.test.generated.StreamingAggregatorGen250.outputToBatchPrev():322
>
> org.apache.drill.exec.test.generated.StreamingAggregatorGen250.doWork():182
>
> org.apache.drill.exec.physical.impl.aggregate.StreamingAggBatch.innerNext():170
> org.apache.drill.exec.record.AbstractRecordBatch.next():162
> org.apache.drill.exec.physical.impl.BaseRootExec.next():105
>
> org.apache.drill.exec.physical.impl.partitionsender.PartitionSenderRootExec.innerNext():144
> org.apache.drill.exec.physical.impl.BaseRootExec.next():95
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():234
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():227
> java.security.AccessController.doPrivileged():-2
> javax.security.auth.Subject.doAs():415
> org.apache.hadoop.security.UserGroupInformation.doAs():1595
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():227
> org.apache.drill.common.SelfCleaningRunnable.run():38
> java.util.concurrent.ThreadPoolExecutor.runWorker():1145
> java.util.concurrent.ThreadPoolExecutor$Worker.run():615
> java.lang.Thread.run():745
> at
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:489)
> at org.apache.drill.jdbc.impl.DrillCursor.next(DrillCursor.java:593)
> at
> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:215)
> at
> org.apache.drill.jdbc.impl.DrillResultSetImpl.next(DrillResultSetImpl.java:140)
> at PipSQueak.fetchRows(PipSQueak.java:420)
> at PipSQueak.runTest(PipSQueak.java:116)
> at PipSQueak.main(PipSQueak.java:556)
> Caused by: org.apache.drill.common.exceptions.UserRemoteException: SYSTEM
> ERROR: NullPointerException
> Fragment 1:1
> [Error Id: ba4661b4-2ff6-4eff-889c-fc4604a57418 on ucs-node8.perf.lab:31010]
> (java.lang.NullPointerException) null
> org.apache.drill.exec.vector.VarCharVector$Mutator.setSafe():607
> org.apache.drill.exec.vector.NullableVarCharVector$Mutator.setSafe():560
>
> org.apache.drill.exec.test.generated.StreamingAggregatorGen250.outputRecordKeysPrev():525
>
> org.apache.drill.exec.test.generated.StreamingAggregatorGen250.outputToBatchPrev():322
>
> org.apache.drill.exec.test.generated.StreamingAggregatorGen250.doWork():182
>
> org.apache.drill.exec.physical.impl.aggregate.StreamingAggBatch.innerNext():170
> org.apache.drill.exec.record.AbstractRecordBatch.next():162
> org.apache.drill.exec.physical.impl.BaseRootExec.next():105
>
> org.apache.drill.exec.physical.impl.partitionsender.PartitionSenderRootExec.innerNext():144
> org.apache.drill.exec.physical.impl.BaseRootExec.next():95
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():234
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():227
> java.security.AccessController.doPrivileged():-2
> javax.security.auth.Subject.doAs():415
> org.apache.hadoop.security.UserGroupInformation.doAs():1595
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():227
> org.apache.drill.common.SelfCleaningRunnable.run():38
> java.util.concurrent.ThreadPoolExecutor.runWorker():1145
> java.util.concurrent.ThreadPoolExecutor$Worker.run():615
> java.lang.Thread.run():745
> at
> org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:123)
> at org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:343)
>
[jira] [Commented] (DRILL-5702) Jdbc Driver Class not found
[
https://issues.apache.org/jira/browse/DRILL-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266142#comment-16266142
]
Holger Kiel commented on DRILL-5702:
All files were taken from the binary distribution archive. When building from
source, the error (Maven property appearing in the classpath) doesn't occur.
> Jdbc Driver Class not found
> ---
>
> Key: DRILL-5702
> URL: https://issues.apache.org/jira/browse/DRILL-5702
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
>Affects Versions: 1.11.0
>Reporter: Holger Kiel
>Priority: Critical
>
> Cannot connect to drill cluster after upgrade to new Jar
> drill-jdbc-all-1.11.0.jar. When replacing Jar file with older release
> drill-jdbc-all-1.10.0.jar, connection works again. Tested with various client
> applications:
> {code}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.ClassNotFoundException: Class
> ${package.namespace.prefix}org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback
> not found
> at
> oadd.org.apache.hadoop.conf.Configuration.getClass(Configuration.java:2227)
> at oadd.org.apache.hadoop.security.Groups.(Groups.java:80)
> at oadd.org.apache.hadoop.security.Groups.(Groups.java:74)
> at
> oadd.org.apache.hadoop.security.Groups.getUserToGroupsMappingService(Groups.java:303)
> at
> oadd.org.apache.hadoop.security.UserGroupInformation.initialize(UserGroupInformation.java:283)
> at
> oadd.org.apache.hadoop.security.UserGroupInformation.setConfiguration(UserGroupInformation.java:311)
> at
> oadd.org.apache.drill.exec.rpc.security.plain.PlainFactory.createAndLoginUser(PlainFactory.java:63)
> at
> oadd.org.apache.drill.exec.rpc.user.UserClient.authenticate(UserClient.java:244)
> at
> oadd.org.apache.drill.exec.rpc.user.UserClient.connect(UserClient.java:171)
> at
> oadd.org.apache.drill.exec.client.DrillClient.connect(DrillClient.java:432)
> at
> oadd.org.apache.drill.exec.client.DrillClient.connect(DrillClient.java:379)
> at
> org.apache.drill.jdbc.impl.DrillConnectionImpl.(DrillConnectionImpl.java:158)
> at
> org.apache.drill.jdbc.impl.DrillJdbc41Factory.newDrillConnection(DrillJdbc41Factory.java:72)
> at
> org.apache.drill.jdbc.impl.DrillFactory.newConnection(DrillFactory.java:69)
> at
> oadd.org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:143)
> at org.apache.drill.jdbc.Driver.connect(Driver.java:72)
> at java.sql.DriverManager.getConnection(DriverManager.java:664)
> at java.sql.DriverManager.getConnection(DriverManager.java:208)
> {code}
> Workaround is using the old driver version.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DRILL-4824) Null maps / lists and non-provided state support for JSON fields. Numeric types promotion.
[
https://issues.apache.org/jira/browse/DRILL-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266122#comment-16266122
]
Paul Rogers commented on DRILL-4824:
Recently had reason to review Drill's existing List and Union support. Seems
that the original Drill designers intended those to satisfy the use case
outlined in this JIRA.
A Union can contain any combination of:
* Null value
* One or more Drill types
Thus, a union of a map provides a nullable map.
(The union does go on to allow, say, either a map or a Varchar, or or a map or
a list, or any other combination. So, a union by itself may be overkill to
achieve just a nullable map.)
A list provides:
* An array of any type (including unions)
* A null flag per row.
Thus, with a list, one can have lists with empty or null values. For example,
with repeated types, Drill can represent only {{\[1, 2, 3]}} but lists can also
support {{\[1, null, 3]}}.
The drawback seems to be that list and union support are limited in Drill.
Unions have their own issues. (See DRILL-5955.)
But, if there is a JSON use case for nulls in maps in arrays, lists are the
existing solution. Since they exist in the product, none of the compatibility
issues discussed above apply: clients already understand lists (though we'd
have to check if the ODBC and JDBC clients correctly handle them.)
Our effort would then turn to the many operators that do not currently support
lists.
> Null maps / lists and non-provided state support for JSON fields. Numeric
> types promotion.
> --
>
> Key: DRILL-4824
> URL: https://issues.apache.org/jira/browse/DRILL-4824
> Project: Apache Drill
> Issue Type: Improvement
> Components: Storage - JSON
>Affects Versions: 1.0.0
>Reporter: Roman Kulyk
>Assignee: Volodymyr Vysotskyi
>
> There is incorrect output in case of JSON file with complex nested data.
> _JSON:_
> {code:none|title=example.json|borderStyle=solid}
> {
> "Field1" : {
> }
> }
> {
> "Field1" : {
> "InnerField1": {"key1":"value1"},
> "InnerField2": {"key2":"value2"}
> }
> }
> {
> "Field1" : {
> "InnerField3" : ["value3", "value4"],
> "InnerField4" : ["value5", "value6"]
> }
> }
> {code}
> _Query:_
> {code:sql}
> select Field1 from dfs.`/tmp/example.json`
> {code}
> _Incorrect result:_
> {code:none}
> +---+
> | Field1 |
> +---+
> {"InnerField1":{},"InnerField2":{},"InnerField3":[],"InnerField4":[]}
> {"InnerField1":{"key1":"value1"},"InnerField2"
> {"key2":"value2"},"InnerField3":[],"InnerField4":[]}
> {"InnerField1":{},"InnerField2":{},"InnerField3":["value3","value4"],"InnerField4":["value5","value6"]}
> +--+
> {code}
> Theres is no need to output missing fields. In case of deeply nested
> structure we will get unreadable result for user.
> _Correct result:_
> {code:none}
> +--+
> | Field1 |
> +--+
> |{}
> {"InnerField1":{"key1":"value1"},"InnerField2":{"key2":"value2"}}
> {"InnerField3":["value3","value4"],"InnerField4":["value5","value6"]}
> +--+
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DRILL-5975) Resource utilization
[ https://issues.apache.org/jira/browse/DRILL-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266114#comment-16266114 ] Paul Rogers commented on DRILL-5975: Thanks [~weijie] for the description of the workload. I wonder if yours is a special case? You mentioned the use of Druid, which, as I recall, does its own aggregation across the multi-dimensional records stored in each of its data chunks. That is unlike the usual Drill use case in which Drill does the work of reading from disk, decoding data, and performing aggregation. It may be worth exploring the differences that Druid introduces. First, what is the architecture between Drill and Druid? Does Drill send queries to Druid brokers for distribution, or does Drill connect directly to historical or real-time nodes? Second, does Druid run on the same cluster as Drill? If so, how do you ensure that each Drillbit reads only from the historical or real-time node on that same node (for data locality?) Or, is Druid on a separate cluster? How, then, do you coordinate between the, say, 120 Drill nodes and the however many Druid nodes? Third, how many queries can Druid effectively run per node? When running a Drill query, what is the CPU load on the Druid cluster? Fourth, left to its own, Drill will try to run 16 * 70% = 11 Druid readers per major fragment per node. Given your knowledge of Drill internals, you may have adjusted that number. If left unchanged, each Drill query will fire off 120 nodes * 11 readers/node = 1320 Druid queries. The above suggests that this particular configuration may be limited by Druid, not by Drill itself. As mentioned earlier, most (non-Druid) Drill clusters are CPU-bound because the do the grunt-work of reading data, decoding, filtering and so on. In the Druid use case, Druid does all that work; Drill may just be sitting around waiting for the work to be done by Druid. This is easy to test, just look at the CPU usage on the Druid cluster when running Drill queries. If Druid turns out to be the bottleneck, you may want to determine the best throughput for Druid nodes: how man queries, with which distribution, maximizes the Druid hardware? Then, work out the size of the Drill cluster needed to drive Druid fully. It may be that you simply have to large a Drill cluster for the available Druid throughput, most Drill tasks just wait for data. Fewer Drill resources may better utilize the Drill cluster. Said yet another way, you have two distributed systems, each trying to spread work: Drill and Druid. They may be working at cross purposes. Certainly their sizing needs to be coordinated for even workload. On the other hand, if neither Drill nor Druid are near 100% CPU, then there is an even more complex interaction happening between the two systems. As hinted above, perhaps Drill and Druid should exist on the same cluster, with Drill taking the place of the Druid coordinator: Drill ships queries directly to the historical or real-time nodes on the same node as the Drillbit. Under this revised architecture, the goal is to drive each Drill/Druid node to full CPU usage. Perhaps the scheduler design is intended to address this use case. If so, then perhaps you could add a bit more explanation about how that will work. > Resource utilization > > > Key: DRILL-5975 > URL: https://issues.apache.org/jira/browse/DRILL-5975 > Project: Apache Drill > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: weijie.tong >Assignee: weijie.tong > > h1. Motivation > Now the resource utilization radio of Drill's cluster is not too good. Most > of the cluster resource is wasted. We can not afford too much concurrent > queries. Once the system accepted more queries with a not high cpu load, the > query which originally is very quick will become slower and slower. > The reason is Drill does not supply a scheduler . It just assume all the > nodes have enough calculation resource. Once a query comes, it will schedule > the related fragments to random nodes not caring about the node's load. Some > nodes will suffer more cpu context switch to satisfy the coming query. The > profound causes to this is that the runtime minor fragments construct a > runtime tree whose nodes spread different drillbits. The runtime tree is a > memory pipeline that is all the nodes will stay alone the whole lifecycle of > a query by sending out data to upper nodes successively, even though some > node could run quickly and quit immediately.What's more the runtime tree is > constructed before actual running. The schedule target to Drill will become > the whole runtime tree nodes. > h1. Design > It will be hard to schedule the runtime tree nodes as a whole. So I try to > solve this by breaking the runtime cascade nodes. The graph below describes >
[jira] [Commented] (DRILL-5986) Update jackson-databind version to 2.7.9.1
[
https://issues.apache.org/jira/browse/DRILL-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266070#comment-16266070
]
ASF GitHub Bot commented on DRILL-5986:
---
Github user asfgit closed the pull request at:
https://github.com/apache/drill/pull/1046
> Update jackson-databind version to 2.7.9.1
> --
>
> Key: DRILL-5986
> URL: https://issues.apache.org/jira/browse/DRILL-5986
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Volodymyr Vysotskyi
> Labels: ready-to-commit
> Fix For: 1.12.0
>
>
> Currently, Drill uses module {{jackson-databind}} v. 2.7.8. The goal of this
> Jira is to update {{Jackson}} version to 2.7.9 and {{jackson-databind}} to
> 2.7.9.1 since few critical bugs were fixed in this version.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DRILL-5952) Implement "CREATE TABLE IF NOT EXISTS"
[ https://issues.apache.org/jira/browse/DRILL-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266072#comment-16266072 ] ASF GitHub Bot commented on DRILL-5952: --- Github user asfgit closed the pull request at: https://github.com/apache/drill/pull/1033 > Implement "CREATE TABLE IF NOT EXISTS" > -- > > Key: DRILL-5952 > URL: https://issues.apache.org/jira/browse/DRILL-5952 > Project: Apache Drill > Issue Type: Improvement > Components: SQL Parser >Affects Versions: 1.11.0 >Reporter: Prasad Nagaraj Subramanya >Assignee: Prasad Nagaraj Subramanya > Labels: doc-impacting, ready-to-commit > Fix For: 1.12.0 > > > Currently, if a table/view with the same name exists CREATE TABLE fails with > VALIDATION ERROR > Having "IF NOT EXISTS" support for CREATE TABLE will ensure that query > succeeds > Also the same functionality was added for views. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DRILL-5981) Add Syntax Highlighting and Error Checking to Storage Plugin Config Page
[ https://issues.apache.org/jira/browse/DRILL-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266071#comment-16266071 ] ASF GitHub Bot commented on DRILL-5981: --- Github user asfgit closed the pull request at: https://github.com/apache/drill/pull/1043 > Add Syntax Highlighting and Error Checking to Storage Plugin Config Page > > > Key: DRILL-5981 > URL: https://issues.apache.org/jira/browse/DRILL-5981 > Project: Apache Drill > Issue Type: Improvement > Components: Web Server >Affects Versions: 1.11.0 >Reporter: Charles Givre >Assignee: Charles Givre > Labels: doc-impacting, ready-to-commit > Fix For: 1.12.0 > > > When configuring storage plugins, it is easy to make a trivial mistake such > as missing a comma or paren, and then spend a great deal of time trying to > find that. This PR adds syntax highlighting and error checking to the > storage plugin page to prevent that. > Note, I work on a closed network and I have included the bare minimum of > javascript libraries needed for this task. I did include them directly in > the PR because I will not be able to build Drill if I have to download them > directly during the build process. > *For documentation* > Consider updating screenshots for storage plugins section. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DRILL-5987) Two versions of javassist on the classpath
[
https://issues.apache.org/jira/browse/DRILL-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266069#comment-16266069
]
ASF GitHub Bot commented on DRILL-5987:
---
Github user asfgit closed the pull request at:
https://github.com/apache/drill/pull/1048
> Two versions of javassist on the classpath
> --
>
> Key: DRILL-5987
> URL: https://issues.apache.org/jira/browse/DRILL-5987
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: Timothy Farkas
>Assignee: Timothy Farkas
> Labels: ready-to-commit
> Fix For: 1.12.0
>
>
> Selected output from maven dependency tree
> {code}
> [INFO]
>
> [INFO] Building Logical Plan, Base expressions 1.12.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @ drill-logical ---
> [INFO] org.apache.drill:drill-logical:jar:1.12.0-SNAPSHOT
> [INFO] +- org.apache.drill:drill-protocol:jar:1.12.0-SNAPSHOT:compile
> [INFO] | +- com.google.protobuf:protobuf-java:jar:2.5.0:compile
> [INFO] | +- com.dyuproject.protostuff:protostuff-core:jar:1.0.8:compile
> [INFO] | | \- com.dyuproject.protostuff:protostuff-api:jar:1.0.8:compile
> [INFO] | \- com.dyuproject.protostuff:protostuff-json:jar:1.0.8:compile
> [INFO] | \- org.codehaus.jackson:jackson-core-asl:jar:1.9.13:compile
> [INFO] +- org.apache.drill:drill-common:jar:1.12.0-SNAPSHOT:compile
> [INFO] +- org.apache.drill:drill-common:jar:tests:1.12.0-SNAPSHOT:test
> [INFO] +- junit:junit:jar:4.11:compile
> [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:compile
> [INFO] +- org.apache.calcite:calcite-core:jar:1.4.0-drill-r23:compile
> [INFO] | +- org.apache.calcite:calcite-avatica:jar:1.4.0-drill-r23:compile
> [INFO] | +- org.apache.calcite:calcite-linq4j:jar:1.4.0-drill-r23:compile
> [INFO] | +- commons-dbcp:commons-dbcp:jar:1.4:compile
> [INFO] | | \- commons-pool:commons-pool:jar:1.5.4:compile
> [INFO] | +- com.google.code.findbugs:jsr305:jar:1.3.9:compile
> [INFO] | +- net.hydromatic:eigenbase-properties:jar:1.1.5:compile
> [INFO] | +- org.codehaus.janino:janino:jar:2.7.6:compile
> [INFO] | +- org.codehaus.janino:commons-compiler:jar:2.7.6:compile
> [INFO] | \- org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde:compile
> [INFO] | \- commons-lang:commons-lang:jar:2.4:compile
> [INFO] +- com.typesafe:config:jar:1.0.0:compile
> [INFO] +- org.apache.commons:commons-lang3:jar:3.1:compile
> [INFO] +- org.msgpack:msgpack:jar:0.6.6:compile
> [INFO] | +- com.googlecode.json-simple:json-simple:jar:1.1.1:compile
> [INFO] | \- org.javassist:javassist:jar:3.16.1-GA:compile
> [INFO] +- org.reflections:reflections:jar:0.9.8:compile
> [INFO] | +- javassist:javassist:jar:3.12.1.GA:compile
> [INFO] | \- dom4j:dom4j:jar:1.6.1:compile
> [INFO] | \- xml-apis:xml-apis:jar:1.0.b2:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DRILL-4286) Have an ability to put server in quiescent mode of operation
[
https://issues.apache.org/jira/browse/DRILL-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266067#comment-16266067
]
ASF GitHub Bot commented on DRILL-4286:
---
Github user arina-ielchiieva commented on the issue:
https://github.com/apache/drill/pull/921
There are unit test failures with this fix. Full output is attached into
Jira. Please check and fix.
```
TestMetadataProvider.columns:251 expected:<92> but was:<93>
DrillSeparatePlanningTest.testMultiMinorFragmentComplexQuery:122->getResultsHelper:219
expected:<1> but was:<0>
DrillSeparatePlanningTest.testSingleFragmentQuery:88->getResultsHelper:219
expected:<1> but was:<0>
DrillSeparatePlanningTest.testMultiMinorFragmentSimpleQuery:105->getResultsHelper:219
expected:<1> but was:<0>
```
> Have an ability to put server in quiescent mode of operation
>
>
> Key: DRILL-4286
> URL: https://issues.apache.org/jira/browse/DRILL-4286
> Project: Apache Drill
> Issue Type: New Feature
> Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Victoria Markman
>Assignee: Venkata Jyothsna Donapati
> Labels: doc-impacting, ready-to-commit
> Fix For: 1.12.0
>
> Attachments: consoleText.txt
>
>
> I think drill will benefit from mode of operation that is called "quiescent"
> in some databases.
> From IBM Informix server documentation:
> {code}
> Change gracefully from online to quiescent mode
> Take the database server gracefully from online mode to quiescent mode to
> restrict access to the database server without interrupting current
> processing. After you perform this task, the database server sets a flag that
> prevents new sessions from gaining access to the database server. The current
> sessions are allowed to finish processing. After you initiate the mode
> change, it cannot be canceled. During the mode change from online to
> quiescent, the database server is considered to be in Shutdown mode.
> {code}
> This is different from shutdown, when processes are terminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DRILL-4779) Kafka storage plugin support
[ https://issues.apache.org/jira/browse/DRILL-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266065#comment-16266065 ] ASF GitHub Bot commented on DRILL-4779: --- Github user arina-ielchiieva commented on the issue: https://github.com/apache/drill/pull/1027 Could not cherry-pick changes into merge branch. Please check and fix: ``` $ git cherry-pick 4b984baf4ad78fbfd7bf21cf58fb91ff3a74be88^..a690b97074376a65ac0c1d86ee2a9fa32e997003 On branch MERGE-112617-00 You are currently cherry-picking commit d375eeb. nothing to commit, working directory clean The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty If you wish to skip this commit, use: git reset Then "git cherry-pick --continue" will resume cherry-picking the remaining commits. ``` > Kafka storage plugin support > > > Key: DRILL-4779 > URL: https://issues.apache.org/jira/browse/DRILL-4779 > Project: Apache Drill > Issue Type: New Feature > Components: Storage - Other >Affects Versions: 1.11.0 >Reporter: B Anil Kumar >Assignee: B Anil Kumar > Labels: doc-impacting, ready-to-commit > Fix For: 1.12.0 > > > Implement Kafka storage plugin will enable the strong SQL support for Kafka. > Initially implementation can target for supporting json and avro message types -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DRILL-4286) Have an ability to put server in quiescent mode of operation
[
https://issues.apache.org/jira/browse/DRILL-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-4286:
Attachment: consoleText.txt
> Have an ability to put server in quiescent mode of operation
>
>
> Key: DRILL-4286
> URL: https://issues.apache.org/jira/browse/DRILL-4286
> Project: Apache Drill
> Issue Type: New Feature
> Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Victoria Markman
>Assignee: Venkata Jyothsna Donapati
> Labels: doc-impacting, ready-to-commit
> Fix For: 1.12.0
>
> Attachments: consoleText.txt
>
>
> I think drill will benefit from mode of operation that is called "quiescent"
> in some databases.
> From IBM Informix server documentation:
> {code}
> Change gracefully from online to quiescent mode
> Take the database server gracefully from online mode to quiescent mode to
> restrict access to the database server without interrupting current
> processing. After you perform this task, the database server sets a flag that
> prevents new sessions from gaining access to the database server. The current
> sessions are allowed to finish processing. After you initiate the mode
> change, it cannot be canceled. During the mode change from online to
> quiescent, the database server is considered to be in Shutdown mode.
> {code}
> This is different from shutdown, when processes are terminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DRILL-4779) Kafka storage plugin support
[ https://issues.apache.org/jira/browse/DRILL-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-4779: Labels: doc-impacting ready-to-commit (was: doc-impacting) > Kafka storage plugin support > > > Key: DRILL-4779 > URL: https://issues.apache.org/jira/browse/DRILL-4779 > Project: Apache Drill > Issue Type: New Feature > Components: Storage - Other >Affects Versions: 1.11.0 >Reporter: B Anil Kumar >Assignee: B Anil Kumar > Labels: doc-impacting, ready-to-commit > Fix For: 1.12.0 > > > Implement Kafka storage plugin will enable the strong SQL support for Kafka. > Initially implementation can target for supporting json and avro message types -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DRILL-4286) Have an ability to put server in quiescent mode of operation
[
https://issues.apache.org/jira/browse/DRILL-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-4286:
Labels: doc-impacting ready-to-commit (was: doc-impacting)
> Have an ability to put server in quiescent mode of operation
>
>
> Key: DRILL-4286
> URL: https://issues.apache.org/jira/browse/DRILL-4286
> Project: Apache Drill
> Issue Type: New Feature
> Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Victoria Markman
>Assignee: Venkata Jyothsna Donapati
> Labels: doc-impacting, ready-to-commit
> Fix For: 1.12.0
>
>
> I think drill will benefit from mode of operation that is called "quiescent"
> in some databases.
> From IBM Informix server documentation:
> {code}
> Change gracefully from online to quiescent mode
> Take the database server gracefully from online mode to quiescent mode to
> restrict access to the database server without interrupting current
> processing. After you perform this task, the database server sets a flag that
> prevents new sessions from gaining access to the database server. The current
> sessions are allowed to finish processing. After you initiate the mode
> change, it cannot be canceled. During the mode change from online to
> quiescent, the database server is considered to be in Shutdown mode.
> {code}
> This is different from shutdown, when processes are terminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DRILL-4779) Kafka storage plugin support
[ https://issues.apache.org/jira/browse/DRILL-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265995#comment-16265995 ] ASF GitHub Bot commented on DRILL-4779: --- Github user arina-ielchiieva commented on the issue: https://github.com/apache/drill/pull/1027 +1, LGTM. > Kafka storage plugin support > > > Key: DRILL-4779 > URL: https://issues.apache.org/jira/browse/DRILL-4779 > Project: Apache Drill > Issue Type: New Feature > Components: Storage - Other >Affects Versions: 1.11.0 >Reporter: B Anil Kumar >Assignee: B Anil Kumar > Labels: doc-impacting, ready-to-commit > Fix For: 1.12.0 > > > Implement Kafka storage plugin will enable the strong SQL support for Kafka. > Initially implementation can target for supporting json and avro message types -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DRILL-4286) Have an ability to put server in quiescent mode of operation
[
https://issues.apache.org/jira/browse/DRILL-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-4286:
Labels: ready-to-commit (was: )
> Have an ability to put server in quiescent mode of operation
>
>
> Key: DRILL-4286
> URL: https://issues.apache.org/jira/browse/DRILL-4286
> Project: Apache Drill
> Issue Type: New Feature
> Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Victoria Markman
>Assignee: Venkata Jyothsna Donapati
> Labels: doc-impacting
> Fix For: 1.12.0
>
>
> I think drill will benefit from mode of operation that is called "quiescent"
> in some databases.
> From IBM Informix server documentation:
> {code}
> Change gracefully from online to quiescent mode
> Take the database server gracefully from online mode to quiescent mode to
> restrict access to the database server without interrupting current
> processing. After you perform this task, the database server sets a flag that
> prevents new sessions from gaining access to the database server. The current
> sessions are allowed to finish processing. After you initiate the mode
> change, it cannot be canceled. During the mode change from online to
> quiescent, the database server is considered to be in Shutdown mode.
> {code}
> This is different from shutdown, when processes are terminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DRILL-4286) Have an ability to put server in quiescent mode of operation
[
https://issues.apache.org/jira/browse/DRILL-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-4286:
Fix Version/s: 1.12.0
> Have an ability to put server in quiescent mode of operation
>
>
> Key: DRILL-4286
> URL: https://issues.apache.org/jira/browse/DRILL-4286
> Project: Apache Drill
> Issue Type: New Feature
> Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Victoria Markman
>Assignee: Venkata Jyothsna Donapati
> Labels: ready-to-commit
> Fix For: 1.12.0
>
>
> I think drill will benefit from mode of operation that is called "quiescent"
> in some databases.
> From IBM Informix server documentation:
> {code}
> Change gracefully from online to quiescent mode
> Take the database server gracefully from online mode to quiescent mode to
> restrict access to the database server without interrupting current
> processing. After you perform this task, the database server sets a flag that
> prevents new sessions from gaining access to the database server. The current
> sessions are allowed to finish processing. After you initiate the mode
> change, it cannot be canceled. During the mode change from online to
> quiescent, the database server is considered to be in Shutdown mode.
> {code}
> This is different from shutdown, when processes are terminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DRILL-4286) Have an ability to put server in quiescent mode of operation
[
https://issues.apache.org/jira/browse/DRILL-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-4286:
Labels: doc-impacting (was: ready-to-commit)
> Have an ability to put server in quiescent mode of operation
>
>
> Key: DRILL-4286
> URL: https://issues.apache.org/jira/browse/DRILL-4286
> Project: Apache Drill
> Issue Type: New Feature
> Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Victoria Markman
>Assignee: Venkata Jyothsna Donapati
> Labels: doc-impacting
> Fix For: 1.12.0
>
>
> I think drill will benefit from mode of operation that is called "quiescent"
> in some databases.
> From IBM Informix server documentation:
> {code}
> Change gracefully from online to quiescent mode
> Take the database server gracefully from online mode to quiescent mode to
> restrict access to the database server without interrupting current
> processing. After you perform this task, the database server sets a flag that
> prevents new sessions from gaining access to the database server. The current
> sessions are allowed to finish processing. After you initiate the mode
> change, it cannot be canceled. During the mode change from online to
> quiescent, the database server is considered to be in Shutdown mode.
> {code}
> This is different from shutdown, when processes are terminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DRILL-4286) Have an ability to put server in quiescent mode of operation
[
https://issues.apache.org/jira/browse/DRILL-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265994#comment-16265994
]
ASF GitHub Bot commented on DRILL-4286:
---
Github user arina-ielchiieva commented on the issue:
https://github.com/apache/drill/pull/921
+1, LGTM.
> Have an ability to put server in quiescent mode of operation
>
>
> Key: DRILL-4286
> URL: https://issues.apache.org/jira/browse/DRILL-4286
> Project: Apache Drill
> Issue Type: New Feature
> Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Victoria Markman
>Assignee: Venkata Jyothsna Donapati
>
> I think drill will benefit from mode of operation that is called "quiescent"
> in some databases.
> From IBM Informix server documentation:
> {code}
> Change gracefully from online to quiescent mode
> Take the database server gracefully from online mode to quiescent mode to
> restrict access to the database server without interrupting current
> processing. After you perform this task, the database server sets a flag that
> prevents new sessions from gaining access to the database server. The current
> sessions are allowed to finish processing. After you initiate the mode
> change, it cannot be canceled. During the mode change from online to
> quiescent, the database server is considered to be in Shutdown mode.
> {code}
> This is different from shutdown, when processes are terminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DRILL-4286) Have an ability to put server in quiescent mode of operation
[
https://issues.apache.org/jira/browse/DRILL-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-4286:
Affects Version/s: 1.11.0
> Have an ability to put server in quiescent mode of operation
>
>
> Key: DRILL-4286
> URL: https://issues.apache.org/jira/browse/DRILL-4286
> Project: Apache Drill
> Issue Type: New Feature
> Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Victoria Markman
>Assignee: Venkata Jyothsna Donapati
>
> I think drill will benefit from mode of operation that is called "quiescent"
> in some databases.
> From IBM Informix server documentation:
> {code}
> Change gracefully from online to quiescent mode
> Take the database server gracefully from online mode to quiescent mode to
> restrict access to the database server without interrupting current
> processing. After you perform this task, the database server sets a flag that
> prevents new sessions from gaining access to the database server. The current
> sessions are allowed to finish processing. After you initiate the mode
> change, it cannot be canceled. During the mode change from online to
> quiescent, the database server is considered to be in Shutdown mode.
> {code}
> This is different from shutdown, when processes are terminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
