[jira] [Updated] (IMPALA-8781) Add additional tests in test_result_spooling.py and validate cancellation logic
[
https://issues.apache.org/jira/browse/IMPALA-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sahil Takiar updated IMPALA-8781:
-
Summary: Add additional tests in test_result_spooling.py and validate
cancellation logic (was: Add stress tests in test_result_spooling.py and
validate cancellation logic)
> Add additional tests in test_result_spooling.py and validate cancellation
> logic
> ---
>
> Key: IMPALA-8781
> URL: https://issues.apache.org/jira/browse/IMPALA-8781
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
>Reporter: Sahil Takiar
>Assignee: Sahil Takiar
>Priority: Major
>
> {{test_result_spooling.py}} currently runs a few basic tests with result
> spooling enabled. We should add some more and validate the cancellation logic
> in {{PlanRootSink}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-8781) Add stress tests in test_result_spooling.py and validate cancellation logic
Sahil Takiar created IMPALA-8781:
Summary: Add stress tests in test_result_spooling.py and validate
cancellation logic
Key: IMPALA-8781
URL: https://issues.apache.org/jira/browse/IMPALA-8781
Project: IMPALA
Issue Type: Sub-task
Components: Backend
Reporter: Sahil Takiar
Assignee: Sahil Takiar
{{test_result_spooling.py}} currently runs a few basic tests with result
spooling enabled. We should add some more and validate the cancellation logic
in {{PlanRootSink}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-8780) Implementation of BufferedPlanRootSink where FlushFinal blocks until all rows are fetched
Sahil Takiar created IMPALA-8780:
Summary: Implementation of BufferedPlanRootSink where FlushFinal
blocks until all rows are fetched
Key: IMPALA-8780
URL: https://issues.apache.org/jira/browse/IMPALA-8780
Project: IMPALA
Issue Type: Sub-task
Components: Backend
Reporter: Sahil Takiar
Assignee: Sahil Takiar
Implement {{BufferedPlanRootSink}} so that {{FlushFinal}} blocks until all rows
are fetched. The implementation should use the {{RowBatchQueue}} introduced by
IMPALA-8779. By blocking in {{FlushFinal}} all non-coordinator fragments will
be closed if all results fit in the {{RowBatchQueue}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-8780) Implementation of BufferedPlanRootSink where FlushFinal blocks until all rows are fetched
Sahil Takiar created IMPALA-8780:
Summary: Implementation of BufferedPlanRootSink where FlushFinal
blocks until all rows are fetched
Key: IMPALA-8780
URL: https://issues.apache.org/jira/browse/IMPALA-8780
Project: IMPALA
Issue Type: Sub-task
Components: Backend
Reporter: Sahil Takiar
Assignee: Sahil Takiar
Implement {{BufferedPlanRootSink}} so that {{FlushFinal}} blocks until all rows
are fetched. The implementation should use the {{RowBatchQueue}} introduced by
IMPALA-8779. By blocking in {{FlushFinal}} all non-coordinator fragments will
be closed if all results fit in the {{RowBatchQueue}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IMPALA-8779) Add RowBatchQueue interface with an implementation backed by a std::queue
[
https://issues.apache.org/jira/browse/IMPALA-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sahil Takiar updated IMPALA-8779:
-
Description:
Add a {{RowBatchQueue}} interface with an implementation backed by a
{{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}-es
will help with the implementation of {{BufferedPlanRootSink}}. Rather than tie
the {{BufferedPlanRootSink}} to a specific method of queuing row batches, we
can use an interface. In future patches, a {{RowBatchQueue}} backed by a
{{BufferedTupleStream}} can easily be switched out in {{BufferedPlanRootSink}}.
We should consider re-factoring the existing {{RowBatchQueue}} to use the new
interface as well.
was:
Add a {{RowBatchQueue}} interface with an implementation backed by a
{{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}es will
help with the implementation of {{BufferedPlanRootSink}}. Rather than tie the
{{BufferedPlanRootSink}} to a specific method of queuing row batches, we can
use an interface. In future patches, a {{RowBatchQueue}} backed by a
{{BufferedTupleStream}} can easily be switched out in {{BufferedPlanRootSink}}.
We should consider re-factoring the existing {{RowBatchQueue}} to use the new
interface as well.
> Add RowBatchQueue interface with an implementation backed by a std::queue
> -
>
> Key: IMPALA-8779
> URL: https://issues.apache.org/jira/browse/IMPALA-8779
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
>Reporter: Sahil Takiar
>Assignee: Sahil Takiar
>Priority: Major
>
> Add a {{RowBatchQueue}} interface with an implementation backed by a
> {{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}-es
> will help with the implementation of {{BufferedPlanRootSink}}. Rather than
> tie the {{BufferedPlanRootSink}} to a specific method of queuing row batches,
> we can use an interface. In future patches, a {{RowBatchQueue}} backed by a
> {{BufferedTupleStream}} can easily be switched out in
> {{BufferedPlanRootSink}}.
> We should consider re-factoring the existing {{RowBatchQueue}} to use the new
> interface as well.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-8779) Add RowBatchQueue interface with an implementation backed by a std::queue
[
https://issues.apache.org/jira/browse/IMPALA-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sahil Takiar updated IMPALA-8779:
-
Description:
Add a {{RowBatchQueue}} interface with an implementation backed by a
{{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}} es
will help with the implementation of {{BufferedPlanRootSink}}. Rather than tie
the {{BufferedPlanRootSink}} to a specific method of queuing row batches, we
can use an interface. In future patches, a {{RowBatchQueue}} backed by a
{{BufferedTupleStream}} can easily be switched out in {{BufferedPlanRootSink}}.
We should consider re-factoring the existing {{RowBatchQueue}} to use the new
interface as well.
was:
Add a {{RowBatchQueue}} interface with an implementation backed by a
{{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}es will
help with the implementation of {{BufferedPlanRootSink}}. Rather than tie the
{{BufferedPlanRootSink}} to a specific method of queuing row batches, we can
use an interface. In future patches, a {{RowBatchQueue}} backed by a
{{BufferedTupleStream}} can easily be switched out in {{BufferedPlanRootSink}}.
We should consider re-factoring the existing {{RowBatchQueue}} to use the new
interface as well.
> Add RowBatchQueue interface with an implementation backed by a std::queue
> -
>
> Key: IMPALA-8779
> URL: https://issues.apache.org/jira/browse/IMPALA-8779
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
>Reporter: Sahil Takiar
>Assignee: Sahil Takiar
>Priority: Major
>
> Add a {{RowBatchQueue}} interface with an implementation backed by a
> {{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}} es
> will help with the implementation of {{BufferedPlanRootSink}}. Rather than
> tie the {{BufferedPlanRootSink}} to a specific method of queuing row batches,
> we can use an interface. In future patches, a {{RowBatchQueue}} backed by a
> {{BufferedTupleStream}} can easily be switched out in
> {{BufferedPlanRootSink}}.
> We should consider re-factoring the existing {{RowBatchQueue}} to use the new
> interface as well.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-8779) Add RowBatchQueue interface with an implementation backed by a std::queue
[
https://issues.apache.org/jira/browse/IMPALA-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sahil Takiar updated IMPALA-8779:
-
Description:
Add a {{RowBatchQueue}} interface with an implementation backed by a
{{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}es will
help with the implementation of {{BufferedPlanRootSink}}. Rather than tie the
{{BufferedPlanRootSink}} to a specific method of queuing row batches, we can
use an interface. In future patches, a {{RowBatchQueue}} backed by a
{{BufferedTupleStream}} can easily be switched out in {{BufferedPlanRootSink}}.
We should consider re-factoring the existing {{RowBatchQueue}} to use the new
interface as well.
was:
Add a {{RowBatchQueue}} interface with an implementation backed by a
{{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}es will
help with the implementation of {{BufferedTupleSink}}. Rather than tie the
{{BufferedTupleSink}} to a specific method of queuing row batches, we can use
an interface. In future patches, a {{RowBatchQueue}} backed by a
{{BufferedTupleStream}} can easily be switched out in {{BufferedTupleSink}}.
We should consider re-factoring the existing {{RowBatchQueue}} to use the new
interface as well.
> Add RowBatchQueue interface with an implementation backed by a std::queue
> -
>
> Key: IMPALA-8779
> URL: https://issues.apache.org/jira/browse/IMPALA-8779
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
>Reporter: Sahil Takiar
>Assignee: Sahil Takiar
>Priority: Major
>
> Add a {{RowBatchQueue}} interface with an implementation backed by a
> {{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}es
> will help with the implementation of {{BufferedPlanRootSink}}. Rather than
> tie the {{BufferedPlanRootSink}} to a specific method of queuing row batches,
> we can use an interface. In future patches, a {{RowBatchQueue}} backed by a
> {{BufferedTupleStream}} can easily be switched out in
> {{BufferedPlanRootSink}}.
> We should consider re-factoring the existing {{RowBatchQueue}} to use the new
> interface as well.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-8779) Add RowBatchQueue interface with an implementation backed by a std::queue
Sahil Takiar created IMPALA-8779:
Summary: Add RowBatchQueue interface with an implementation backed
by a std::queue
Key: IMPALA-8779
URL: https://issues.apache.org/jira/browse/IMPALA-8779
Project: IMPALA
Issue Type: Sub-task
Components: Backend
Reporter: Sahil Takiar
Assignee: Sahil Takiar
Add a {{RowBatchQueue}} interface with an implementation backed by a
{{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}es will
help with the implementation of {{BufferedTupleSink}}. Rather than tie the
{{BufferedTupleSink}} to a specific method of queuing row batches, we can use
an interface. In future patches, a {{RowBatchQueue}} backed by a
{{BufferedTupleStream}} can easily be switched out in {{BufferedTupleSink}}.
We should consider re-factoring the existing {{RowBatchQueue}} to use the new
interface as well.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-8779) Add RowBatchQueue interface with an implementation backed by a std::queue
Sahil Takiar created IMPALA-8779:
Summary: Add RowBatchQueue interface with an implementation backed
by a std::queue
Key: IMPALA-8779
URL: https://issues.apache.org/jira/browse/IMPALA-8779
Project: IMPALA
Issue Type: Sub-task
Components: Backend
Reporter: Sahil Takiar
Assignee: Sahil Takiar
Add a {{RowBatchQueue}} interface with an implementation backed by a
{{std::queue}}. Introducing a generic queue that can buffer {{RowBatch}}es will
help with the implementation of {{BufferedTupleSink}}. Rather than tie the
{{BufferedTupleSink}} to a specific method of queuing row batches, we can use
an interface. In future patches, a {{RowBatchQueue}} backed by a
{{BufferedTupleStream}} can easily be switched out in {{BufferedTupleSink}}.
We should consider re-factoring the existing {{RowBatchQueue}} to use the new
interface as well.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (IMPALA-8777) Beeline timeout to connect to impalad in the minicluster
[
https://issues.apache.org/jira/browse/IMPALA-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v resolved IMPALA-8777.
---
Resolution: Not A Problem
Fix Version/s: Not Applicable
> Beeline timeout to connect to impalad in the minicluster
>
>
> Key: IMPALA-8777
> URL: https://issues.apache.org/jira/browse/IMPALA-8777
> Project: IMPALA
> Issue Type: Bug
>Reporter: Quanlong Huang
>Priority: Major
> Fix For: Not Applicable
>
>
> In the minicluster, I was able to use beeline to connect to HiveServer2:
> {code:java}
> beeline -u "jdbc:hive2://localhost:11050"{code}
> However, connecting to Impalad via beeline will hang forever:
> {code:java}
> beeline -u "jdbc:hive2://localhost:21050"{code}
> jstack result of the beeline client:
> {code:java}
> 2019-07-21 14:07:48
> Full thread dump OpenJDK 64-Bit Server VM (25.212-b03 mixed mode):
> "Attach Listener" #16 daemon prio=9 os_prio=0 tid=0x7f870c2c7000
> nid=0x7a11 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "NonBlockingInputStreamThread" #15 daemon prio=5 os_prio=0
> tid=0x7f8729d13800 nid=0x3dd7 in Object.wait() [0x7f870b4bf000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xfbce17d0> (a
> jline.internal.NonBlockingInputStream)
> at
> jline.internal.NonBlockingInputStream.run(NonBlockingInputStream.java:278)
> - locked <0xfbce17d0> (a jline.internal.NonBlockingInputStream)
> at java.lang.Thread.run(Thread.java:748)
> "Service Thread" #9 daemon prio=9 os_prio=0 tid=0x7f87280f9800 nid=0x3dc6
> runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x7f87280ee800
> nid=0x3dc5 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x7f87280ec800
> nid=0x3dc4 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x7f87280ea800
> nid=0x3dc3 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x7f87280e7800
> nid=0x3dc2 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x7f87280e6000
> nid=0x3dc1 runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x7f87280b3800 nid=0x3dc0 in
> Object.wait() [0x7f87127e6000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xff589210> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
> - locked <0xff589210> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x7f87280b1000
> nid=0x3dbf in Object.wait() [0x7f87128e7000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xff5893c8> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:502)
> at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> - locked <0xff5893c8> (a java.lang.ref.Reference$Lock)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> "main" #1 prio=5 os_prio=0 tid=0x7f872802d800 nid=0x3db3 runnable
> [0x7f8731696000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0xfcf31708> (a java.io.BufferedInputStream)
> at
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
> at
> org.apache.thrift.transport.TSaslTransport.receiveSaslMessage(TSaslTransport.java:178)
> at
> org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:305)
>
[jira] [Resolved] (IMPALA-8777) Beeline timeout to connect to impalad in the minicluster
[
https://issues.apache.org/jira/browse/IMPALA-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v resolved IMPALA-8777.
---
Resolution: Not A Problem
Fix Version/s: Not Applicable
> Beeline timeout to connect to impalad in the minicluster
>
>
> Key: IMPALA-8777
> URL: https://issues.apache.org/jira/browse/IMPALA-8777
> Project: IMPALA
> Issue Type: Bug
>Reporter: Quanlong Huang
>Priority: Major
> Fix For: Not Applicable
>
>
> In the minicluster, I was able to use beeline to connect to HiveServer2:
> {code:java}
> beeline -u "jdbc:hive2://localhost:11050"{code}
> However, connecting to Impalad via beeline will hang forever:
> {code:java}
> beeline -u "jdbc:hive2://localhost:21050"{code}
> jstack result of the beeline client:
> {code:java}
> 2019-07-21 14:07:48
> Full thread dump OpenJDK 64-Bit Server VM (25.212-b03 mixed mode):
> "Attach Listener" #16 daemon prio=9 os_prio=0 tid=0x7f870c2c7000
> nid=0x7a11 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "NonBlockingInputStreamThread" #15 daemon prio=5 os_prio=0
> tid=0x7f8729d13800 nid=0x3dd7 in Object.wait() [0x7f870b4bf000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xfbce17d0> (a
> jline.internal.NonBlockingInputStream)
> at
> jline.internal.NonBlockingInputStream.run(NonBlockingInputStream.java:278)
> - locked <0xfbce17d0> (a jline.internal.NonBlockingInputStream)
> at java.lang.Thread.run(Thread.java:748)
> "Service Thread" #9 daemon prio=9 os_prio=0 tid=0x7f87280f9800 nid=0x3dc6
> runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x7f87280ee800
> nid=0x3dc5 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x7f87280ec800
> nid=0x3dc4 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x7f87280ea800
> nid=0x3dc3 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x7f87280e7800
> nid=0x3dc2 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x7f87280e6000
> nid=0x3dc1 runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x7f87280b3800 nid=0x3dc0 in
> Object.wait() [0x7f87127e6000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xff589210> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
> - locked <0xff589210> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x7f87280b1000
> nid=0x3dbf in Object.wait() [0x7f87128e7000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xff5893c8> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:502)
> at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> - locked <0xff5893c8> (a java.lang.ref.Reference$Lock)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> "main" #1 prio=5 os_prio=0 tid=0x7f872802d800 nid=0x3db3 runnable
> [0x7f8731696000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0xfcf31708> (a java.io.BufferedInputStream)
> at
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
> at
> org.apache.thrift.transport.TSaslTransport.receiveSaslMessage(TSaslTransport.java:178)
> at
> org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:305)
>
[jira] [Commented] (IMPALA-8777) Beeline timeout to connect to impalad in the minicluster
[
https://issues.apache.org/jira/browse/IMPALA-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890607#comment-16890607
]
bharath v commented on IMPALA-8777:
---
I think this has something to do with HIVE-4232. Beeline is picking bad
defaults. I haven't had a chance to dig into why it is picking the right
default for HS2 URL though. May be we are doing [something
special|https://github.com/apache/impala/blob/5466cf6344af893521b093915aba25fde6b13d4e/fe/src/test/resources/hive-site.xml.py#L52]
in the configs.
> Beeline timeout to connect to impalad in the minicluster
>
>
> Key: IMPALA-8777
> URL: https://issues.apache.org/jira/browse/IMPALA-8777
> Project: IMPALA
> Issue Type: Bug
>Reporter: Quanlong Huang
>Priority: Major
>
> In the minicluster, I was able to use beeline to connect to HiveServer2:
> {code:java}
> beeline -u "jdbc:hive2://localhost:11050"{code}
> However, connecting to Impalad via beeline will hang forever:
> {code:java}
> beeline -u "jdbc:hive2://localhost:21050"{code}
> jstack result of the beeline client:
> {code:java}
> 2019-07-21 14:07:48
> Full thread dump OpenJDK 64-Bit Server VM (25.212-b03 mixed mode):
> "Attach Listener" #16 daemon prio=9 os_prio=0 tid=0x7f870c2c7000
> nid=0x7a11 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "NonBlockingInputStreamThread" #15 daemon prio=5 os_prio=0
> tid=0x7f8729d13800 nid=0x3dd7 in Object.wait() [0x7f870b4bf000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xfbce17d0> (a
> jline.internal.NonBlockingInputStream)
> at
> jline.internal.NonBlockingInputStream.run(NonBlockingInputStream.java:278)
> - locked <0xfbce17d0> (a jline.internal.NonBlockingInputStream)
> at java.lang.Thread.run(Thread.java:748)
> "Service Thread" #9 daemon prio=9 os_prio=0 tid=0x7f87280f9800 nid=0x3dc6
> runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x7f87280ee800
> nid=0x3dc5 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x7f87280ec800
> nid=0x3dc4 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x7f87280ea800
> nid=0x3dc3 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x7f87280e7800
> nid=0x3dc2 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x7f87280e6000
> nid=0x3dc1 runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x7f87280b3800 nid=0x3dc0 in
> Object.wait() [0x7f87127e6000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xff589210> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
> - locked <0xff589210> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x7f87280b1000
> nid=0x3dbf in Object.wait() [0x7f87128e7000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xff5893c8> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:502)
> at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> - locked <0xff5893c8> (a java.lang.ref.Reference$Lock)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> "main" #1 prio=5 os_prio=0 tid=0x7f872802d800 nid=0x3db3 runnable
> [0x7f8731696000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0xfcf31708> (a java.io.BufferedInputStream)
> at
>
[jira] [Updated] (IMPALA-8470) Impala Doc: Use a more human-readable flag to switch to a different authorization provider
[ https://issues.apache.org/jira/browse/IMPALA-8470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-8470: Issue Type: Task (was: Bug) > Impala Doc: Use a more human-readable flag to switch to a different > authorization provider > -- > > Key: IMPALA-8470 > URL: https://issues.apache.org/jira/browse/IMPALA-8470 > Project: IMPALA > Issue Type: Task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc, in_33 > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7936) Enable better control over Parquet writing
[ https://issues.apache.org/jira/browse/IMPALA-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890554#comment-16890554 ] Alex Rodoni commented on IMPALA-7936: - [~boroknagyz] . [~lv] The PARQUET_READ_PAGE_INDEX query option is not documented. Does it need to be documented along with these 2 new query options? Or is it undocumented for a reason? > Enable better control over Parquet writing > -- > > Key: IMPALA-7936 > URL: https://issues.apache.org/jira/browse/IMPALA-7936 > Project: IMPALA > Issue Type: Improvement >Reporter: Zoltán Borók-Nagy >Assignee: Zoltán Borók-Nagy >Priority: Major > Fix For: Impala 3.3.0 > > > With the introduction of the Parquet page indexes it became desirable to have > more control over how Impala writes Parquet files. > These configuration options (probably implemented as query options) would be: > * enable/disable Parquet page index writing (currently we can do it with a > command-line argument) > * set page-size limits based on row count > * -Set truncation length for statistics about string values- (current > truncation length is 64, it is unlikely to have user data that needs longer > truncation than that) > They'd enable writing more complete tests for page filtering. They'd be also > useful for fine-tuning the page index for better performance. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-8701) Document idle session management after IMPALA-7802
[
https://issues.apache.org/jira/browse/IMPALA-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890543#comment-16890543
]
Alex Rodoni commented on IMPALA-8701:
-
https://gerrit.cloudera.org/#/c/13896/
> Document idle session management after IMPALA-7802
> --
>
> Key: IMPALA-8701
> URL: https://issues.apache.org/jira/browse/IMPALA-8701
> Project: IMPALA
> Issue Type: Task
> Components: Docs
>Affects Versions: Impala 3.3.0
>Reporter: Michael Ho
>Assignee: Alex Rodoni
>Priority: Major
> Labels: future_release_doc, in_33
>
> After IMPALA-7802 is fixed, the network connection of an idle session will be
> closed {{\-\-idle_client_poll_time_s}} seconds latest after the session has
> been declared idle. This is a change of behavior from previous versions in
> which the client connection will hang around until the user explicitly closes
> the session and disconnects.
> By default, {{\-\-idle_client_poll_time_s}} is set to 30 seconds and the
> previous behavior can be restored by setting to 0. In addition, the session
> will only be closed if idle session timeout has been configured to be greater
> than 0 for the session either via the startup flag {{--idle_session_timeout}}
> or the query option {{IDLE_SESSION_TIMEOUT}}. If idle session timeout is not
> configured, a session cannot become idle by definition and therefore its
> connection cannot be closed until the client explicitly closes it.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Work started] (IMPALA-8701) Document idle session management after IMPALA-7802
[
https://issues.apache.org/jira/browse/IMPALA-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on IMPALA-8701 started by Alex Rodoni.
---
> Document idle session management after IMPALA-7802
> --
>
> Key: IMPALA-8701
> URL: https://issues.apache.org/jira/browse/IMPALA-8701
> Project: IMPALA
> Issue Type: Task
> Components: Docs
>Affects Versions: Impala 3.3.0
>Reporter: Michael Ho
>Assignee: Alex Rodoni
>Priority: Major
> Labels: future_release_doc, in_33
>
> After IMPALA-7802 is fixed, the network connection of an idle session will be
> closed {{\-\-idle_client_poll_time_s}} seconds latest after the session has
> been declared idle. This is a change of behavior from previous versions in
> which the client connection will hang around until the user explicitly closes
> the session and disconnects.
> By default, {{\-\-idle_client_poll_time_s}} is set to 30 seconds and the
> previous behavior can be restored by setting to 0. In addition, the session
> will only be closed if idle session timeout has been configured to be greater
> than 0 for the session either via the startup flag {{--idle_session_timeout}}
> or the query option {{IDLE_SESSION_TIMEOUT}}. If idle session timeout is not
> configured, a session cannot become idle by definition and therefore its
> connection cannot be closed until the client explicitly closes it.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-8701) Document idle session management after IMPALA-7802
[
https://issues.apache.org/jira/browse/IMPALA-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rodoni updated IMPALA-8701:
Issue Type: Task (was: Documentation)
> Document idle session management after IMPALA-7802
> --
>
> Key: IMPALA-8701
> URL: https://issues.apache.org/jira/browse/IMPALA-8701
> Project: IMPALA
> Issue Type: Task
> Components: Docs
>Affects Versions: Impala 3.3.0
>Reporter: Michael Ho
>Assignee: Alex Rodoni
>Priority: Major
> Labels: future_release_doc, in_33
>
> After IMPALA-7802 is fixed, the network connection of an idle session will be
> closed {{\-\-idle_client_poll_time_s}} seconds latest after the session has
> been declared idle. This is a change of behavior from previous versions in
> which the client connection will hang around until the user explicitly closes
> the session and disconnects.
> By default, {{\-\-idle_client_poll_time_s}} is set to 30 seconds and the
> previous behavior can be restored by setting to 0. In addition, the session
> will only be closed if idle session timeout has been configured to be greater
> than 0 for the session either via the startup flag {{--idle_session_timeout}}
> or the query option {{IDLE_SESSION_TIMEOUT}}. If idle session timeout is not
> configured, a session cannot become idle by definition and therefore its
> connection cannot be closed until the client explicitly closes it.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-8334) Impala Doc: Document impala-shell config_file format
[ https://issues.apache.org/jira/browse/IMPALA-8334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-8334: Labels: (was: future_release_doc in_33) > Impala Doc: Document impala-shell config_file format > > > Key: IMPALA-8334 > URL: https://issues.apache.org/jira/browse/IMPALA-8334 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Closed] (IMPALA-8727) Impala Doc: DDL Docs Update for Kudu / HMS Integration
[ https://issues.apache.org/jira/browse/IMPALA-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-8727. --- Resolution: Fixed Fix Version/s: Impala 3.3.0 > Impala Doc: DDL Docs Update for Kudu / HMS Integration > --- > > Key: IMPALA-8727 > URL: https://issues.apache.org/jira/browse/IMPALA-8727 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc, in_33 > Fix For: Impala 3.3.0 > > > https://gerrit.cloudera.org/#/c/13776/ -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (IMPALA-8727) Impala Doc: DDL Docs Update for Kudu / HMS Integration
[ https://issues.apache.org/jira/browse/IMPALA-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-8727. --- Resolution: Fixed Fix Version/s: Impala 3.3.0 > Impala Doc: DDL Docs Update for Kudu / HMS Integration > --- > > Key: IMPALA-8727 > URL: https://issues.apache.org/jira/browse/IMPALA-8727 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc, in_33 > Fix For: Impala 3.3.0 > > > https://gerrit.cloudera.org/#/c/13776/ -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-8727) Impala Doc: DDL Docs Update for Kudu / HMS Integration
[ https://issues.apache.org/jira/browse/IMPALA-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890444#comment-16890444 ] ASF subversion and git services commented on IMPALA-8727: - Commit 5466cf6344af893521b093915aba25fde6b13d4e in impala's branch refs/heads/master from Alex Rodoni [ https://gitbox.apache.org/repos/asf?p=impala.git;h=5466cf6 ] IMPALA-8727: [DOCS] Impala-side changes for Kudu HMS integration Change-Id: Ieec79ac0bbb860c6394a3bf0617b285a7d23ca9e Reviewed-on: http://gerrit.cloudera.org:8080/13776 Reviewed-by: Alexey Serbin Tested-by: Impala Public Jenkins Reviewed-by: Andrew Wong Reviewed-by: Thomas Tauber-Marshall > Impala Doc: DDL Docs Update for Kudu / HMS Integration > --- > > Key: IMPALA-8727 > URL: https://issues.apache.org/jira/browse/IMPALA-8727 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc, in_33 > > https://gerrit.cloudera.org/#/c/13776/ -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-8742) ScannerContext::eosr() should depends on scan_range->bytes_to_read() instead of scan_range->len()
[ https://issues.apache.org/jira/browse/IMPALA-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Armstrong reassigned IMPALA-8742: - Assignee: Zoltán Borók-Nagy > ScannerContext::eosr() should depends on scan_range->bytes_to_read() instead > of scan_range->len() > - > > Key: IMPALA-8742 > URL: https://issues.apache.org/jira/browse/IMPALA-8742 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 3.2.0 >Reporter: Chen Wang >Assignee: Zoltán Borók-Nagy >Priority: Minor > > Normally, scan_range->len() equals to scan_range->bytes_to_read(). > But when SubRanges exists, only bytes_to_read was updated, > ScannerContext::GetBuffer would read entire scan_range->len() bytes, and I > think it would be a bug. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-8742) ScannerContext::eosr() should depends on scan_range->bytes_to_read() instead of scan_range->len()
[ https://issues.apache.org/jira/browse/IMPALA-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890377#comment-16890377 ] Tim Armstrong commented on IMPALA-8742: --- [~boroknagyz] do you think there is anything to this bug report? > ScannerContext::eosr() should depends on scan_range->bytes_to_read() instead > of scan_range->len() > - > > Key: IMPALA-8742 > URL: https://issues.apache.org/jira/browse/IMPALA-8742 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 3.2.0 >Reporter: Chen Wang >Assignee: Zoltán Borók-Nagy >Priority: Minor > > Normally, scan_range->len() equals to scan_range->bytes_to_read(). > But when SubRanges exists, only bytes_to_read was updated, > ScannerContext::GetBuffer would read entire scan_range->len() bytes, and I > think it would be a bug. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-8778) Support read/write Apache Hudi tables
Yuanbin Cheng created IMPALA-8778: - Summary: Support read/write Apache Hudi tables Key: IMPALA-8778 URL: https://issues.apache.org/jira/browse/IMPALA-8778 Project: IMPALA Issue Type: New Feature Reporter: Yuanbin Cheng Assignee: Yuanbin Cheng Apache Impala currently not support Apache Hudi, cannot even pull metadata from Hive. Related issue: [https://github.com/apache/incubator-hudi/issues/179] [https://issues.apache.org/jira/projects/HUDI/issues/HUDI-146|https://issues.apache.org/jira/projects/HUDI/issues/HUDI-146?filter=allopenissues] -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-8778) Support read/write Apache Hudi tables
Yuanbin Cheng created IMPALA-8778: - Summary: Support read/write Apache Hudi tables Key: IMPALA-8778 URL: https://issues.apache.org/jira/browse/IMPALA-8778 Project: IMPALA Issue Type: New Feature Reporter: Yuanbin Cheng Assignee: Yuanbin Cheng Apache Impala currently not support Apache Hudi, cannot even pull metadata from Hive. Related issue: [https://github.com/apache/incubator-hudi/issues/179] [https://issues.apache.org/jira/projects/HUDI/issues/HUDI-146|https://issues.apache.org/jira/projects/HUDI/issues/HUDI-146?filter=allopenissues] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (IMPALA-8622) Generate list of docker images generated by the build
[
https://issues.apache.org/jira/browse/IMPALA-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong reassigned IMPALA-8622:
-
Assignee: Tim Armstrong (was: Harshil Shah)
> Generate list of docker images generated by the build
> -
>
> Key: IMPALA-8622
> URL: https://issues.apache.org/jira/browse/IMPALA-8622
> Project: IMPALA
> Issue Type: Sub-task
> Components: Infrastructure
>Reporter: Tim Armstrong
>Assignee: Tim Armstrong
>Priority: Major
> Labels: docker
>
> Some consumers of the Impala docker images will want to publish them to a
> repo. Currently they would have to hardcode a list of the docker images
> produced by the Impala build to publish them, or do something brittle like
> "docker image ls" to deduce what images were built.
> It would be useful if the build produced a list of the images in some
> consumable format that would be updated (either manually or automatically)
> when the set of images changes. If it needs to be manually updated, we should
> have some kind of check to verify that it isn't stale.
> One option is to produce JSON, something like:
> {noformat}
> {
> “docker_images”: {
>“impala_base”: “$docker_registry/impala_base”,
>” impalad_coord_exec”: “$docker_registry/impalad_coord_exec”,
>
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
