Failed: OOZIE-3160 PreCommit Build #871
Jira: https://issues.apache.org/jira/browse/OOZIE-3160
Build: https://builds.apache.org/job/PreCommit-OOZIE-Build/871/
###
## LAST 100 LINES OF THE CONSOLE
###
[...truncated 1.88 MB...]
[DEBUG] There are no new bugs found in [sharelib/pig].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [sharelib/oozie].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [sharelib/sqoop].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [sharelib/distcp].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [sharelib/spark].
[INFO] There are no new bugs found totally].
[TRACE] FindBugs diffs checked and reports created
[TRACE] Summary file size is 2486 bytes
[TRACE] Full summary file size is 1471 bytes
[TRACE] File
[/home/jenkins/jenkins-slave/workspace/PreCommit-OOZIE-Build/test-patch/tmp/FINDBUGS_DIFF/diff/findbugs-diff-0.1.0-all.jar]
removed
[TRACE] File
[/home/jenkins/jenkins-slave/workspace/PreCommit-OOZIE-Build/test-patch/tmp/FINDBUGS_DIFF/diff/findbugs-diff-0.1.0-all.jar.md5sum]
removed
Running test-patch task BACKWARDS_COMPATIBILITY
Running test-patch task TESTS
Running test-patch task DISTRO
Testing JIRA OOZIE-3160
Cleaning local git workspace
+1 PATCH_APPLIES
+1 CLEAN
+1 RAW_PATCH_ANALYSIS
+1 the patch does not introduce any @author tags
+1 the patch does not introduce any tabs
+1 the patch does not introduce any trailing spaces
+1 the patch does not introduce any line longer than 132
+1 the patch adds/modifies 2 testcase(s)
+1 RAT
+1 the patch does not seem to introduce new RAT warnings
+1 JAVADOC
+1 Javadoc generation succeeded with the patch
+1 the patch does not seem to introduce new Javadoc warning(s)
WARNING: the current HEAD has 100 Javadoc warning(s)
+1 COMPILE
+1 HEAD compiles
+1 patch compiles
+1 the patch does not seem to introduce new javac warnings
+1 There are no new bugs found in total.
+1 There are no new bugs found in [webapp].
+1 There are no new bugs found in [examples].
+1 There are no new bugs found in [server].
+1 There are no new bugs found in [client].
+1 There are no new bugs found in [docs].
+1 There are no new bugs found in [fluent-job/fluent-job-api].
+1 There are no new bugs found in [core].
+1 There are no new bugs found in [tools].
+1 There are no new bugs found in [sharelib/streaming].
+1 There are no new bugs found in [sharelib/hive2].
+1 There are no new bugs found in [sharelib/git].
+1 There are no new bugs found in [sharelib/hcatalog].
+1 There are no new bugs found in [sharelib/hive].
+1 There are no new bugs found in [sharelib/pig].
+1 There are no new bugs found in [sharelib/oozie].
+1 There are no new bugs found in [sharelib/sqoop].
+1 There are no new bugs found in [sharelib/distcp].
+1 There are no new bugs found in [sharelib/spark].
+1 BACKWARDS_COMPATIBILITY
+1 the patch does not change any JPA Entity/Colum/Basic/Lob/Transient
annotations
+1 the patch does not modify JPA files
-1 TESTS
Tests run: 2995
Tests failed : 0
Tests in error : 0
Tests timed out : 1
Check console output for the full list of errors/failures
+1 DISTRO
+1 distro tarball builds with the patch
-1 Overall result, please check the reported -1(s)
There is at least one warning, please check
The full output of the test-patch run is available at
https://builds.apache.org/job/PreCommit-OOZIE-Build/871/
Adding comment to JIRA
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0{"self":"https://issues.apache.org/jira/rest/api/2/issue/13130774/comment/16632000","id":"16632000","author":{"self":"https://issues.apache.org/jira/rest/api/2/user?username=hadoopqa","name":"hadoopqa","key":"hadoopqa","avatarUrls":{"48x48":"https://issues.apache.org/jira/secure/useravatar?ownerId=hadoopqa=10393","24x24":"https://issues.apache.org/jira/secure/useravatar?size=small=hadoopqa=10393","16x16":"https://issues.apache.org/jira/secure/useravatar?size=xsmall=hadoopqa=10393","32x32":"https://issues.apache.org/jira/secure/useravatar?size=medium=hadoopqa=10393"},"displayName":"Hadoop
QA","active":true,"timeZone":"Etc/UTC"},"body":"\nTesting JIRA
OOZIE-3160\n\nCleaning local git
workspace\n\n\n\n{color:green}+1
PATCH_APPLIES{color}\n{color:green}+1
[jira] [Commented] (OOZIE-3160) PriorityDelayQueue put()/take() can cause significant CPU load due to busy waiting
[
https://issues.apache.org/jira/browse/OOZIE-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16632000#comment-16632000
]
Hadoop QA commented on OOZIE-3160:
--
Testing JIRA OOZIE-3160
Cleaning local git workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:green}+1{color} the patch adds/modifies 2 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} Javadoc generation succeeded with the patch
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warning(s)
.{color:orange}WARNING{color}: the current HEAD has 100 Javadoc warning(s)
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1{color} There are no new bugs found in total.
. {color:green}+1{color} There are no new bugs found in [webapp].
. {color:green}+1{color} There are no new bugs found in [examples].
. {color:green}+1{color} There are no new bugs found in [server].
. {color:green}+1{color} There are no new bugs found in [client].
. {color:green}+1{color} There are no new bugs found in [docs].
. {color:green}+1{color} There are no new bugs found in
[fluent-job/fluent-job-api].
. {color:green}+1{color} There are no new bugs found in [core].
. {color:green}+1{color} There are no new bugs found in [tools].
. {color:green}+1{color} There are no new bugs found in [sharelib/streaming].
. {color:green}+1{color} There are no new bugs found in [sharelib/hive2].
. {color:green}+1{color} There are no new bugs found in [sharelib/git].
. {color:green}+1{color} There are no new bugs found in [sharelib/hcatalog].
. {color:green}+1{color} There are no new bugs found in [sharelib/hive].
. {color:green}+1{color} There are no new bugs found in [sharelib/pig].
. {color:green}+1{color} There are no new bugs found in [sharelib/oozie].
. {color:green}+1{color} There are no new bugs found in [sharelib/sqoop].
. {color:green}+1{color} There are no new bugs found in [sharelib/distcp].
. {color:green}+1{color} There are no new bugs found in [sharelib/spark].
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
.Tests run: 2995
.Tests failed : 0
.Tests in error : 0
.Tests timed out : 1
Check console output for the full list of errors/failures
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
{color:red}. There is at least one warning, please check{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/PreCommit-OOZIE-Build/871/
> PriorityDelayQueue put()/take() can cause significant CPU load due to busy
> waiting
> --
>
> Key: OOZIE-3160
> URL: https://issues.apache.org/jira/browse/OOZIE-3160
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: trunk
> Environment: all platforms
>Reporter: jj
>Assignee: Peter Bacsko
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: 11.png, 22.png,
> OOZIE-3160-001.patch, OOZIE-3160-002.patch, OOZIE-3160-003.patch,
> OOZIE-3160-004.patch, OOZIE-3160-005.patch, OOZIE-3160-006.patch,
> OOZIE-3160-007.patch, OOZIE-3160-POC01.patch, OOZIE-3160-POC02.patch,
> OOZIE-3160-POC02.patch, OOZIE-3160-POC03.patch, OOZIE-3160-POC04.patch,
> OOZIE-3160-POC05.patch, OOZIE-3160.amend.001.patch,
> OOZIE-3160.amend.002.patch, OOZIE-3160.amend.003.patch, PriorityDelayQueue
> improvement - OOZIE-3160.pdf
>
>
> oozie process always consume high cpu. in my mechine,around 10%.
> I check the source code，find take() method in PriorityDelayQueue class。
> code:
> {code:java}
> public QueueElement take() throws InterruptedException {
> QueueElement e = poll();
> while (e == null) {
> Thread.sleep(10);
> e = poll();
> }
> return e;
> }
> {code}
> i think it's the reason of this
[jira] [Commented] (OOZIE-3355) Regex based search option for searching workflows in the WFM-View of Ambari
[
https://issues.apache.org/jira/browse/OOZIE-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631879#comment-16631879
]
Andras Piros commented on OOZIE-3355:
-
Sounds like a fine improvement [~Krishna93]!
As I'm not familiar with Ambari, can you please tell what are the Oozie
[REST|https://github.com/apache/oozie/blob/master/docs/src/site/markdown/WebServicesAPI.md]
/
[CLI|https://github.com/apache/oozie/blob/master/docs/src/site/markdown/DG_CommandLineTool.md]
calls you want to extend? Can you please also tell typical input / output
examples you want Oozie to support? Thanks!
> Regex based search option for searching workflows in the WFM-View of Ambari
> ---
>
> Key: OOZIE-3355
> URL: https://issues.apache.org/jira/browse/OOZIE-3355
> Project: Oozie
> Issue Type: New Feature
> Components: bundle, coordinator, core, tools, ui, workflow
>Affects Versions: 4.2.0
>Reporter: Krishnadevan Purushothaman
>Priority: Critical
>
> *Challenge faced :*
> _{color:#d04437}In the WFM view of ambari, there is no Filter option
> available to search for the Workflows. In order to search for the desired
> workflow, one has to type the full name of workflow,coordinator,bundles else
> it does not return anything which becomes a time-consuming job.{color}_
> *Feature description:*
> _{color:#14892c}There is a need for Regex based filter option in order to
> search the workflows without the need of entering the complete name of the
> workflow,coordinator,bundles rather by just typing the first three letters of
> the work post which it should populate suggestions based on the first three
> letters of the workflow,coordinator,bundles through which we can refine and
> optimize the searching mechanism.{color}_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3355) Regex based search option for searching workflows in the WFM-View of Ambari
[
https://issues.apache.org/jira/browse/OOZIE-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krishnadevan Purushothaman updated OOZIE-3355:
--
Component/s: coordinator
bundle
> Regex based search option for searching workflows in the WFM-View of Ambari
> ---
>
> Key: OOZIE-3355
> URL: https://issues.apache.org/jira/browse/OOZIE-3355
> Project: Oozie
> Issue Type: New Feature
> Components: bundle, coordinator, core, tools, ui, workflow
>Affects Versions: 4.2.0
>Reporter: Krishnadevan Purushothaman
>Priority: Critical
>
> *Challenge faced :*
> _{color:#d04437}In the WFM view of ambari, there is no Filter option
> available to search for the Workflows. In order to search for the desired
> workflow, one has to type the full name of workflow,coordinator,bundles else
> it does not return anything which becomes a time-consuming job.{color}_
> *Feature description:*
> _{color:#14892c}There is a need for Regex based filter option in order to
> search the workflows without the need of entering the complete name of the
> workflow,coordinator,bundles rather by just typing the first three letters of
> the work post which it should populate suggestions based on the first three
> letters of the workflow,coordinator,bundles through which we can refine and
> optimize the searching mechanism.{color}_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3355) Regex based search option for searching workflows in the WFM-View of Ambari
[
https://issues.apache.org/jira/browse/OOZIE-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krishnadevan Purushothaman updated OOZIE-3355:
--
Description:
*Challenge faced :*
_{color:#d04437}In the WFM view of ambari, there is no Filter option available
to search for the Workflows. In order to search for the desired workflow, one
has to type the full name of workflow,coordinator,bundles else it does not
return anything which becomes a time-consuming job.{color}_
*Feature description:*
_{color:#14892c}There is a need for Regex based filter option in order to
search the workflows without the need of entering the complete name of the
workflow,coordinator,bundles rather by just typing the first three letters of
the work post which it should populate suggestions based on the first three
letters of the workflow,coordinator,bundles through which we can refine and
optimize the searching mechanism.{color}_
was:
*Challenge faced :*
_{color:#d04437}In the WFM view of ambari, there is no Filter option available
to search for the Workflows. In order to search for the desired workflow, one
has to type the full name of workflow else it does not return anything which
becomes a time-consuming job.{color}_
*Feature description:*
_{color:#14892c}There is a need for Regex based filter option in order to
search the workflows without the need of entering the complete name of the
workflow rather by just typing the first three letters of the work post which
it should populate suggestions based on the first three letters of the workflow
through which we can refine and optimize the searching mechanism.{color}_
> Regex based search option for searching workflows in the WFM-View of Ambari
> ---
>
> Key: OOZIE-3355
> URL: https://issues.apache.org/jira/browse/OOZIE-3355
> Project: Oozie
> Issue Type: New Feature
> Components: core, tools, ui, workflow
>Affects Versions: 4.2.0
>Reporter: Krishnadevan Purushothaman
>Priority: Critical
>
> *Challenge faced :*
> _{color:#d04437}In the WFM view of ambari, there is no Filter option
> available to search for the Workflows. In order to search for the desired
> workflow, one has to type the full name of workflow,coordinator,bundles else
> it does not return anything which becomes a time-consuming job.{color}_
> *Feature description:*
> _{color:#14892c}There is a need for Regex based filter option in order to
> search the workflows without the need of entering the complete name of the
> workflow,coordinator,bundles rather by just typing the first three letters of
> the work post which it should populate suggestions based on the first three
> letters of the workflow,coordinator,bundles through which we can refine and
> optimize the searching mechanism.{color}_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631842#comment-16631842
]
Peter Bacsko commented on OOZIE-3354:
-
+1
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch,
> OOZIE-3354.003.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631839#comment-16631839
]
Hadoop QA commented on OOZIE-3354:
--
Testing JIRA OOZIE-3354
Cleaning local git workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:red}-1{color} the patch does not add/modify any testcase
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} Javadoc generation succeeded with the patch
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warning(s)
.{color:orange}WARNING{color}: the current HEAD has 100 Javadoc warning(s)
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1{color} There are no new bugs found in total.
. {color:green}+1{color} There are no new bugs found in [client].
. {color:green}+1{color} There are no new bugs found in [sharelib/hive].
. {color:green}+1{color} There are no new bugs found in [sharelib/sqoop].
. {color:green}+1{color} There are no new bugs found in [sharelib/spark].
. {color:green}+1{color} There are no new bugs found in [sharelib/streaming].
. {color:green}+1{color} There are no new bugs found in [sharelib/hive2].
. {color:green}+1{color} There are no new bugs found in [sharelib/oozie].
. {color:green}+1{color} There are no new bugs found in [sharelib/hcatalog].
. {color:green}+1{color} There are no new bugs found in [sharelib/git].
. {color:green}+1{color} There are no new bugs found in [sharelib/pig].
. {color:green}+1{color} There are no new bugs found in [sharelib/distcp].
. {color:green}+1{color} There are no new bugs found in
[fluent-job/fluent-job-api].
. {color:green}+1{color} There are no new bugs found in [docs].
. {color:green}+1{color} There are no new bugs found in [server].
. {color:green}+1{color} There are no new bugs found in [core].
. {color:green}+1{color} There are no new bugs found in [examples].
. {color:green}+1{color} There are no new bugs found in [webapp].
. {color:green}+1{color} There are no new bugs found in [tools].
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:green}+1 TESTS{color}
.Tests run: 3056
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
{color:red}. There is at least one warning, please check{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/PreCommit-OOZIE-Build/870/
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch,
> OOZIE-3354.003.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
Failed: OOZIE-3354 PreCommit Build #870
Jira: https://issues.apache.org/jira/browse/OOZIE-3354
Build: https://builds.apache.org/job/PreCommit-OOZIE-Build/870/
###
## LAST 100 LINES OF THE CONSOLE
###
[...truncated 1.88 MB...]
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [fluent-job/fluent-job-api].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [docs].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [server].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [core].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [examples].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [webapp].
[TRACE] New XMLLib present, calling 'xmllint --xpath' to get bug instance counts
[DEBUG] There are no new bugs found in [tools].
[INFO] There are no new bugs found totally].
[TRACE] FindBugs diffs checked and reports created
[TRACE] Summary file size is 2487 bytes
[TRACE] Full summary file size is 1471 bytes
[TRACE] File
[/home/jenkins/jenkins-slave/workspace/PreCommit-OOZIE-Build/test-patch/tmp/FINDBUGS_DIFF/diff/findbugs-diff-0.1.0-all.jar]
removed
[TRACE] File
[/home/jenkins/jenkins-slave/workspace/PreCommit-OOZIE-Build/test-patch/tmp/FINDBUGS_DIFF/diff/findbugs-diff-0.1.0-all.jar.md5sum]
removed
Running test-patch task BACKWARDS_COMPATIBILITY
Running test-patch task TESTS
Running test-patch task DISTRO
Testing JIRA OOZIE-3354
Cleaning local git workspace
+1 PATCH_APPLIES
+1 CLEAN
-1 RAW_PATCH_ANALYSIS
+1 the patch does not introduce any @author tags
+1 the patch does not introduce any tabs
+1 the patch does not introduce any trailing spaces
+1 the patch does not introduce any line longer than 132
-1 the patch does not add/modify any testcase
+1 RAT
+1 the patch does not seem to introduce new RAT warnings
+1 JAVADOC
+1 Javadoc generation succeeded with the patch
+1 the patch does not seem to introduce new Javadoc warning(s)
WARNING: the current HEAD has 100 Javadoc warning(s)
+1 COMPILE
+1 HEAD compiles
+1 patch compiles
+1 the patch does not seem to introduce new javac warnings
+1 There are no new bugs found in total.
+1 There are no new bugs found in [client].
+1 There are no new bugs found in [sharelib/hive].
+1 There are no new bugs found in [sharelib/sqoop].
+1 There are no new bugs found in [sharelib/spark].
+1 There are no new bugs found in [sharelib/streaming].
+1 There are no new bugs found in [sharelib/hive2].
+1 There are no new bugs found in [sharelib/oozie].
+1 There are no new bugs found in [sharelib/hcatalog].
+1 There are no new bugs found in [sharelib/git].
+1 There are no new bugs found in [sharelib/pig].
+1 There are no new bugs found in [sharelib/distcp].
+1 There are no new bugs found in [fluent-job/fluent-job-api].
+1 There are no new bugs found in [docs].
+1 There are no new bugs found in [server].
+1 There are no new bugs found in [core].
+1 There are no new bugs found in [examples].
+1 There are no new bugs found in [webapp].
+1 There are no new bugs found in [tools].
+1 BACKWARDS_COMPATIBILITY
+1 the patch does not change any JPA Entity/Colum/Basic/Lob/Transient
annotations
+1 the patch does not modify JPA files
+1 TESTS
Tests run: 3056
+1 DISTRO
+1 distro tarball builds with the patch
-1 Overall result, please check the reported -1(s)
There is at least one warning, please check
The full output of the test-patch run is available at
https://builds.apache.org/job/PreCommit-OOZIE-Build/870/
Adding comment to JIRA
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0{"self":"https://issues.apache.org/jira/rest/api/2/issue/13188002/comment/16631839","id":"16631839","author":{"self":"https://issues.apache.org/jira/rest/api/2/user?username=hadoopqa","name":"hadoopqa","key":"hadoopqa","avatarUrls":{"48x48":"https://issues.apache.org/jira/secure/useravatar?ownerId=hadoopqa=10393","24x24":"https://issues.apache.org/jira/secure/useravatar?size=small=hadoopqa=10393","16x16":"https://issues.apache.org/jira/secure/useravatar?size=xsmall=hadoopqa=10393","32x32":"https://issues.apache.org/jira/secure/useravatar?size=medium=hadoopqa=10393"},"displayName":"Hadoop
[jira] [Created] (OOZIE-3355) Regex based search option for searching workflows in the WFM-View of Ambari
Krishnadevan Purushothaman created OOZIE-3355:
-
Summary: Regex based search option for searching workflows in the
WFM-View of Ambari
Key: OOZIE-3355
URL: https://issues.apache.org/jira/browse/OOZIE-3355
Project: Oozie
Issue Type: New Feature
Components: core, tools, ui, workflow
Affects Versions: 4.2.0
Reporter: Krishnadevan Purushothaman
*Challenge faced :*
_{color:#d04437}In the WFM view of ambari, there is no Filter option available
to search for the Workflows. In order to search for the desired workflow, one
has to type the full name of workflow else it does not return anything which
becomes a time-consuming job.{color}_
*Feature description:*
_{color:#14892c}There is a need for Regex based filter option in order to
search the workflows without the need of entering the complete name of the
workflow rather by just typing the first three letters of the work post which
it should populate suggestions based on the first three letters of the workflow
through which we can refine and optimize the searching mechanism.{color}_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3160) PriorityDelayQueue put()/take() can cause significant CPU load due to busy waiting
[
https://issues.apache.org/jira/browse/OOZIE-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631793#comment-16631793
]
Hadoop QA commented on OOZIE-3160:
--
PreCommit-OOZIE-Build started
> PriorityDelayQueue put()/take() can cause significant CPU load due to busy
> waiting
> --
>
> Key: OOZIE-3160
> URL: https://issues.apache.org/jira/browse/OOZIE-3160
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: trunk
> Environment: all platforms
>Reporter: jj
>Assignee: Peter Bacsko
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: 11.png, 22.png,
> OOZIE-3160-001.patch, OOZIE-3160-002.patch, OOZIE-3160-003.patch,
> OOZIE-3160-004.patch, OOZIE-3160-005.patch, OOZIE-3160-006.patch,
> OOZIE-3160-007.patch, OOZIE-3160-POC01.patch, OOZIE-3160-POC02.patch,
> OOZIE-3160-POC02.patch, OOZIE-3160-POC03.patch, OOZIE-3160-POC04.patch,
> OOZIE-3160-POC05.patch, OOZIE-3160.amend.001.patch,
> OOZIE-3160.amend.002.patch, OOZIE-3160.amend.003.patch, PriorityDelayQueue
> improvement - OOZIE-3160.pdf
>
>
> oozie process always consume high cpu. in my mechine,around 10%.
> I check the source code，find take() method in PriorityDelayQueue class。
> code:
> {code:java}
> public QueueElement take() throws InterruptedException {
> QueueElement e = poll();
> while (e == null) {
> Thread.sleep(10);
> e = poll();
> }
> return e;
> }
> {code}
> i think it's the reason of this problem. it's keep while, not await.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3160) PriorityDelayQueue put()/take() can cause significant CPU load due to busy waiting
[
https://issues.apache.org/jira/browse/OOZIE-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631790#comment-16631790
]
Andras Piros commented on OOZIE-3160:
-
Re-triggering pre-commit build to see what happens w/ test timeouts.
> PriorityDelayQueue put()/take() can cause significant CPU load due to busy
> waiting
> --
>
> Key: OOZIE-3160
> URL: https://issues.apache.org/jira/browse/OOZIE-3160
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: trunk
> Environment: all platforms
>Reporter: jj
>Assignee: Peter Bacsko
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: 11.png, 22.png,
> OOZIE-3160-001.patch, OOZIE-3160-002.patch, OOZIE-3160-003.patch,
> OOZIE-3160-004.patch, OOZIE-3160-005.patch, OOZIE-3160-006.patch,
> OOZIE-3160-007.patch, OOZIE-3160-POC01.patch, OOZIE-3160-POC02.patch,
> OOZIE-3160-POC02.patch, OOZIE-3160-POC03.patch, OOZIE-3160-POC04.patch,
> OOZIE-3160-POC05.patch, OOZIE-3160.amend.001.patch,
> OOZIE-3160.amend.002.patch, OOZIE-3160.amend.003.patch, PriorityDelayQueue
> improvement - OOZIE-3160.pdf
>
>
> oozie process always consume high cpu. in my mechine,around 10%.
> I check the source code，find take() method in PriorityDelayQueue class。
> code:
> {code:java}
> public QueueElement take() throws InterruptedException {
> QueueElement e = poll();
> while (e == null) {
> Thread.sleep(10);
> e = poll();
> }
> return e;
> }
> {code}
> i think it's the reason of this problem. it's keep while, not await.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631716#comment-16631716
]
Hadoop QA commented on OOZIE-3354:
--
PreCommit-OOZIE-Build started
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch,
> OOZIE-3354.003.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631681#comment-16631681
]
Peter Bacsko commented on OOZIE-3354:
-
Ok, this one looks good. Let's wait for Jenkins then I'll +1 it if there are no
errors.
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch,
> OOZIE-3354.003.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Piros updated OOZIE-3354:
Attachment: OOZIE-3354.003.patch
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch,
> OOZIE-3354.003.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631680#comment-16631680
]
Andras Piros commented on OOZIE-3354:
-
Thanks for the review [~pbacsko]! Addressed your comments in patch 003.
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch,
> OOZIE-3354.003.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631675#comment-16631675
]
Peter Bacsko commented on OOZIE-3354:
-
Thoughts from me:
1. Add a short comment that the current solution is kind of like an emergency
solution to a problem that arises when {{Process.waitFor()}} is used. Or sth
like that.
2. Increase sleep to 500ms. 100ms might be too tight.
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631571#comment-16631571
]
Andras Piros commented on OOZIE-3354:
-
Thanks for the review [~asasvari]! Posted another patch that sleeps 100 ms
after draining both buffers when the process hasn't ended yet (in case of
{{IllegalThreadStateException}}).
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Piros updated OOZIE-3354:
Attachment: OOZIE-3354.002.patch
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch, OOZIE-3354.002.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3354) [core] [SSH action] SSH action gets hung
[
https://issues.apache.org/jira/browse/OOZIE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631560#comment-16631560
]
Attila Sasvari commented on OOZIE-3354:
---
[~andras.piros] thanks for the patch! I have run into an issue when an SSH
action with {{}} got hung after an Oozie upgrade.
Can we add some sleep (say 100ms) when an IllegalThreadStateException exception
is thrown to reduce busy-waiting?
> [core] [SSH action] SSH action gets hung
>
>
> Key: OOZIE-3354
> URL: https://issues.apache.org/jira/browse/OOZIE-3354
> Project: Oozie
> Issue Type: Bug
> Components: action, core
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3354.001.patch
>
>
> In OOZIE-3183 {{SshActionExecutor#drainBuffers()}} has changed. Previously,
> it called {{Process#exitCode()}} that would return immediately either with
> the exit code, or would throw an {{IllegalThreadStateException}} if the
> process would still be running.
> In the current implementation introduced by OOZIE-3183, {{Process#waitFor()}}
> is used that would block until the process finishes. Given the fact that
> sometime {{SshActionExecutor#check()}} calls {{ssh ... cat stdout}}, and this
> SSH process can be trapped even after {{cat stdout}} has been finished on the
> target host, it can happen that {{SshActionExecutor#drainBuffers()}} waits
> indefinitely without a chance to gather any {{stdout}} or {{stderr}} logs.
> Hence this particular one is a compatibility breaking change with existing
> SSH action behavior.
> Let's re-introduce the former behavior in
> {{SshActionExecutor#drainBuffers()}} that keeps polling
> {{Process#exitValue()}} and reading the progress on {{stdout}} and {{stderr}}
> till the process finishes, for backwards compatibility.
> [This
> article|https://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html]
> covers the behavioral details of {{Process#waitFor()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] Subscription: Oozie Patch Available
Issue Subscription Filter: Oozie Patch Available (92 issues) Subscriber: ooziedaily Key Summary OOZIE-3354 [core] [SSH action] SSH action gets hung https://issues.apache.org/jira/browse/OOZIE-3354 OOZIE-3338 Remove SVN references https://issues.apache.org/jira/browse/OOZIE-3338 OOZIE-3326 Sqoop Action should support tez delegation tokens for hive-import https://issues.apache.org/jira/browse/OOZIE-3326 OOZIE-3320 Oozie ShellAction should support absolute bash file path https://issues.apache.org/jira/browse/OOZIE-3320 OOZIE-3319 Log SSH action callback error output https://issues.apache.org/jira/browse/OOZIE-3319 OOZIE-3301 Update NOTICE file https://issues.apache.org/jira/browse/OOZIE-3301 OOZIE-3277 [build] Check for star imports in patches in pre-commit https://issues.apache.org/jira/browse/OOZIE-3277 OOZIE-3274 Remove slf4j https://issues.apache.org/jira/browse/OOZIE-3274 OOZIE-3266 Coord action rerun support RERUN_SKIP_NODES option https://issues.apache.org/jira/browse/OOZIE-3266 OOZIE-3265 properties RERUN_FAIL_NODES and RERUN_SKIP_NODES should be able to appear together https://issues.apache.org/jira/browse/OOZIE-3265 OOZIE-3256 refactor OozieCLI class https://issues.apache.org/jira/browse/OOZIE-3256 OOZIE-3249 [tools] Instrumentation log parser https://issues.apache.org/jira/browse/OOZIE-3249 OOZIE-3218 Oozie Sqoop action with command splits the select clause into multiple parts due to delimiter being space https://issues.apache.org/jira/browse/OOZIE-3218 OOZIE-3199 Let system property restriction configurable https://issues.apache.org/jira/browse/OOZIE-3199 OOZIE-3196 Authorization: restrict world readability by user https://issues.apache.org/jira/browse/OOZIE-3196 OOZIE-3194 Oozie should set proper permissions to sharelib after upload https://issues.apache.org/jira/browse/OOZIE-3194 OOZIE-3186 Oozie is unable to use configuration linked using jceks://file/... https://issues.apache.org/jira/browse/OOZIE-3186 OOZIE-3179 Adding a configurable config-default.xml location to a workflow https://issues.apache.org/jira/browse/OOZIE-3179 OOZIE-3170 Oozie Diagnostic Bundle tool fails with NPE due to missing service class https://issues.apache.org/jira/browse/OOZIE-3170 OOZIE-3160 PriorityDelayQueue put()/take() can cause significant CPU load due to busy waiting https://issues.apache.org/jira/browse/OOZIE-3160 OOZIE-3135 Configure log4j2 in SqoopMain https://issues.apache.org/jira/browse/OOZIE-3135 OOZIE-3120 maven-assembly-plugin fails when bumped from 2.2.1 https://issues.apache.org/jira/browse/OOZIE-3120 OOZIE-3091 Oozie Sqoop Avro Import fails with "java.lang.NoClassDefFoundError: org/apache/avro/mapred/AvroWrapper" https://issues.apache.org/jira/browse/OOZIE-3091 OOZIE-3071 Oozie 4.3 Spark sharelib ueses a different version of commons-lang3 than Spark 2.2.0 https://issues.apache.org/jira/browse/OOZIE-3071 OOZIE-3063 Sanitizing variables that are part of openjpa.ConnectionProperties https://issues.apache.org/jira/browse/OOZIE-3063 OOZIE-3062 Set HADOOP_CONF_DIR for spark action https://issues.apache.org/jira/browse/OOZIE-3062 OOZIE-2952 Fix Findbugs warnings in oozie-sharelib-oozie https://issues.apache.org/jira/browse/OOZIE-2952 OOZIE-2949 Escape quotes whitespaces in Sqoop field https://issues.apache.org/jira/browse/OOZIE-2949 OOZIE-2927 Append new line character for Hive2 query using query tag https://issues.apache.org/jira/browse/OOZIE-2927 OOZIE-2834 ParameterVerifier logging non-useful warning for workflow definition https://issues.apache.org/jira/browse/OOZIE-2834 OOZIE-2833 when using uber mode the regex pattern used in the extractHeapSizeMB method does not allow heap sizes specified in bytes. https://issues.apache.org/jira/browse/OOZIE-2833 OOZIE-2812 SparkConfigurationService should support loading configurations from multiple Spark versions https://issues.apache.org/jira/browse/OOZIE-2812 OOZIE-2795 Create lib directory or symlink for Oozie CLI during packaging https://issues.apache.org/jira/browse/OOZIE-2795 OOZIE-2784 Include WEEK as a parameter in the Coordinator Expression Language Evaulator https://issues.apache.org/jira/browse/OOZIE-2784 OOZIE-2779 Mask Hive2 action Beeline JDBC password https://issues.apache.org/jira/browse/OOZIE-2779 OOZIE-2736 Reduce the number of threads during test execution https://issues.apache.org/jira/browse/OOZIE-2736 OOZIE-2714 Detect conflicting resources during class loading https://issues.apache.org/jira/browse/OOZIE-2714 OOZIE-2694 Add logging for FsActionExecutor
