[jira] Subscription: Oozie Patch Available

2018-05-08 Thread jira 
Issue Subscription
Filter: Oozie Patch Available (106 issues)

Subscriber: ooziedaily

Key Summary
OOZIE-3235  Upgrade Old ActiveMQ dependency in Oozie
https://issues.apache.org/jira/browse/OOZIE-3235
OOZIE-3221  Rename DEFAULT_LAUNCHER_MAX_ATTEMPS
https://issues.apache.org/jira/browse/OOZIE-3221
OOZIE-3219  Cannot compile with hadoop 3.1.0
https://issues.apache.org/jira/browse/OOZIE-3219
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-3217  Enable definition of admin users using oozie-site.xml
https://issues.apache.org/jira/browse/OOZIE-3217
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-3193  Applications are not killed when submitted via subworkflow
https://issues.apache.org/jira/browse/OOZIE-3193
OOZIE-3186  Oozie is unable to use configuration linked using jceks://file/...
https://issues.apache.org/jira/browse/OOZIE-3186
OOZIE-3185  Conflicting JARs org.apache.derby exist in Oozie
https://issues.apache.org/jira/browse/OOZIE-3185
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-3135  Configure log4j2 in SqoopMain
https://issues.apache.org/jira/browse/OOZIE-3135
OOZIE-3109  Escape log-streaming's HTML-specific characters
https://issues.apache.org/jira/browse/OOZIE-3109
OOZIE-3105  testJMXInstrumentation from the 
org.apache.oozie.util.TestMetricsInstrumentation class is flaky
https://issues.apache.org/jira/browse/OOZIE-3105
OOZIE-3094  fix for grammar mistake
https://issues.apache.org/jira/browse/OOZIE-3094
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-3061  Kill only those child jobs which are not already killed
https://issues.apache.org/jira/browse/OOZIE-3061
OOZIE-3002  address findbugs errors in client lib
https://issues.apache.org/jira/browse/OOZIE-3002
OOZIE-2975  code clean up in pig sharelib, replace Exception with more 
explicit, add try with resources, StringBuilder instead of StringBuffer
https://issues.apache.org/jira/browse/OOZIE-2975
OOZIE-2956  Fix Findbugs warnings related to reliance on default encoding in 
oozie-core
https://issues.apache.org/jira/browse/OOZIE-2956
OOZIE-2955  Fix Findbugs warnings related to reliance on default encoding in 
oozie-client
https://issues.apache.org/jira/browse/OOZIE-2955
OOZIE-2954  Fix Checkstyle issues in oozie-client
https://issues.apache.org/jira/browse/OOZIE-2954
OOZIE-2953  Fix Checkstyle issues in oozie-tools
https://issues.apache.org/jira/browse/OOZIE-2953
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-2942  [examples] Fix Findbugs warnings
https://issues.apache.org/jira/browse/OOZIE-2942
OOZIE-2927  Append new line character for Hive2 query using query tag
https://issues.apache.org/jira/browse/OOZIE-2927
OOZIE-2883  OOZIE throw the error "Missing 
[oozie.service.ProxyUserService.proxyuser.oozie.service.ProxyUserService.proxyuser.mr.groups]
 property"
https://issues.apache.org/jira/browse/OOZIE-2883
OOZIE-2877  Oozie Git Action
https://issues.apache.org/jira/browse/OOZIE-2877
OOZIE-2867  Timezone handling for Coordinators: emphasize "Continent/City" 
format
https://issues.apache.org/jira/browse/OOZIE-2867
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 al

[jira] [Commented] (OOZIE-3188) Allow a configurable timeout value for the SSH action

2018-05-08 Thread Jason Phelps (JIRA) 

[ 
https://issues.apache.org/jira/browse/OOZIE-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16468092#comment-16468092
 ] 

Jason Phelps commented on OOZIE-3188:
-

Marking this as a duplicate of Oozie-3191, which is more general and a superset 
of this

> Allow a configurable timeout value for the SSH action
> -
>
> Key: OOZIE-3188
> URL: https://issues.apache.org/jira/browse/OOZIE-3188
> Project: Oozie
>  Issue Type: Improvement
>  Components: action
>Affects Versions: 5.0.0b1
>Reporter: Jason Phelps
>Priority: Major
>
> For the SSH action, the timeout value is [hardcoded to 20 
> seconds|https://github.com/apache/oozie/blob/master/core/src/main/java/org/apache/oozie/action/ssh/SshActionExecutor.java#L62].
>  It could be helpful if this timeout value was configurable by an job 
> property, with the default remaining 20 seconds. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OOZIE-3188) Allow a configurable timeout value for the SSH action

2018-05-08 Thread Jason Phelps (JIRA) 

 [ 
https://issues.apache.org/jira/browse/OOZIE-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Phelps resolved OOZIE-3188.
-
Resolution: Duplicate

> Allow a configurable timeout value for the SSH action
> -
>
> Key: OOZIE-3188
> URL: https://issues.apache.org/jira/browse/OOZIE-3188
> Project: Oozie
>  Issue Type: Improvement
>  Components: action
>Affects Versions: 5.0.0b1
>Reporter: Jason Phelps
>Priority: Major
>
> For the SSH action, the timeout value is [hardcoded to 20 
> seconds|https://github.com/apache/oozie/blob/master/core/src/main/java/org/apache/oozie/action/ssh/SshActionExecutor.java#L62].
>  It could be helpful if this timeout value was configurable by an job 
> property, with the default remaining 20 seconds. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Moving Oozie to pull requests

2018-05-08 Thread Robert Kanter 
Is there a way to trigger
https://builds.apache.org/job/PreCommit-OOZIE-Build/ (
https://builds.apache.org/job/PreCommit-Admin/) from a pull request?  We
wouldn't want to lose the pre-commit Jenkins run.

- Robert

On Tue, May 8, 2018 at 7:25 AM, Andras Piros  wrote:

> Hi Geza,
>
> +1 on using GitHub pull requests instead of patches uploaded to ReviewBoard
> / JIRA. PRs are the modern way of doing code reviews, integrating changes,
> doing source code management in general.
>
> This step will lower the barrier newcomers face when trying to contribute
> for the first time, too.
>
> Andras
>
> On Tue, May 8, 2018 at 4:01 PM, Peter Cseh  wrote:
>
> > Hi team Oozie!
> >
> > Many projects are using pull requests on Github instead of uploading
> > patches to Jira.
> > Based on my experience with those projects, pull requests are easier to
> > manage and less error prone than the current way of doing commits in
> Oozie.
> >
> > I would like to migrate Oozie to use pull requests instead of patch files
> > in the next quarter if the community is up for that change.
> > I don't really see any downsides other than we'll have to resubmit some
> > patches for old jiras, which we'll have to do anyways due to possible
> merge
> > conflicts.
> > The tooling and automation possibilities around pull requests will
> probably
> > meet all our needs.
> >
> > I don't know if we'd need an official vote for a change like this or
> > regular Jira is enough to track all the necessary changes. Let's see if
> > there are any objections against the general idea before going too much
> > into details. :)
> >
> > So... Any objections?
> > gp
> >
> >
> > --
> > *Peter Cseh *| Software Engineer
> > cloudera.com 
> >
> > [image: Cloudera] 
> >
> > [image: Cloudera on Twitter]  [image:
> > Cloudera on Facebook]  [image:
> Cloudera
> > on LinkedIn] 
> > --
> >
>

[jira] [Commented] (OOZIE-2715) Provide possibility to set default values for properties of a particular action type

2018-05-08 Thread Andras Piros (JIRA) 

[ 
https://issues.apache.org/jira/browse/OOZIE-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467572#comment-16467572
 ] 

Andras Piros commented on OOZIE-2715:
-

[~gezapeti] this JIRA is about general means of providing default values for 
action types. Another use case is e.g. setting {{oozie.libpath}} for all Sqoop 
actions of all workflows on one Oozie server. To my knowledge it isn't covered 
anywhere, is it?

> Provide possibility to set default values for properties of a particular 
> action type
> 
>
> Key: OOZIE-2715
> URL: https://issues.apache.org/jira/browse/OOZIE-2715
> Project: Oozie
>  Issue Type: Wish
>  Components: action
>Affects Versions: 4.2.0
>Reporter: Istvan Vajnorak
>Priority: Major
>
> When it comes to retrying an action, one can set the default values for a 
> retry on the global level, and the override can happen then on the individual 
> step's level only.
> The proposal to be able to set retry and other properties on an action type 
> basis, could allow defaulting things and help not to do repetitive work on 
> each action instance in the workflow.
> Example:
> - One has 60 shell actions and 30 java actions in a workflow.
> - One sets " oozie.launcher.yarn.resourcemanager.am.max-attempts=1" globally
> - For shell steps they don't want this to get applied, so they have to 
> suppress the retry on those steps each time
> The proposal would allow an intermediate level of override similarly like the 
> hadoop conf allows with the *-default.xml, *-site.xml and code level 
> properties override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OOZIE-3232) Reduce heap waste by reducing duplicate string count

2018-05-08 Thread Andras Piros (JIRA) 

[ 
https://issues.apache.org/jira/browse/OOZIE-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467544#comment-16467544
 ] 

Andras Piros commented on OOZIE-3232:
-

+1

> Reduce heap waste by reducing duplicate string count
> 
>
> Key: OOZIE-3232
> URL: https://issues.apache.org/jira/browse/OOZIE-3232
> Project: Oozie
>  Issue Type: Improvement
>  Components: core
>Reporter: Misha Dmitriev
>Assignee: Misha Dmitriev
>Priority: Major
> Attachments: OOZIE-3232-01.patch, jxray-analysis-dup-strings.png
>
>
> I've recently analyzed an Oozie heap dump obtained from a customer's 
> production job, using jxray (www.jxray.com). In this job, Oozie's heap 
> consumption is ~6GB, and it turns out that nearly 25% of it is wasted due to 
> a large number of duplicate strings. The screenshot below, taken from the 
> jxray report, illustrates the problem.
> !jxray-analysis-dup-strings.png|width=638,height=669!
> It turns out that a lot of duplicate strings come from the oozie's own code, 
> i.e. {{org.apache.oozie.*}}. In particular, the top data field wasting memory 
> is {{org.apache.oozie.StringBlob.string}} (wastes 2.6%, or ~160MB). From the 
> source code of {{StringBlob}} I see that it would be trivial to intern 
> (deduplicate) these strings by adding the call to {{String.intern()}} in the 
> constructor and a few other places. Similarly, various fields of 
> {{org.apache.oozie.WorkflowJobBean}} and {{WorkflowActionBean}} collectively 
> waste a lot of memory, and can be fixed in the same way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OOZIE-3232) Reduce heap waste by reducing duplicate string count

2018-05-08 Thread Andras Piros (JIRA) 

 [ 
https://issues.apache.org/jira/browse/OOZIE-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andras Piros updated OOZIE-3232:

Summary: Reduce heap waste by reducing duplicate string count  (was: Oozie 
may waste up to 25% of the heap due to duplicate strings)

> Reduce heap waste by reducing duplicate string count
> 
>
> Key: OOZIE-3232
> URL: https://issues.apache.org/jira/browse/OOZIE-3232
> Project: Oozie
>  Issue Type: Improvement
>  Components: core
>Reporter: Misha Dmitriev
>Assignee: Misha Dmitriev
>Priority: Major
> Attachments: OOZIE-3232-01.patch, jxray-analysis-dup-strings.png
>
>
> I've recently analyzed an Oozie heap dump obtained from a customer's 
> production job, using jxray (www.jxray.com). In this job, Oozie's heap 
> consumption is ~6GB, and it turns out that nearly 25% of it is wasted due to 
> a large number of duplicate strings. The screenshot below, taken from the 
> jxray report, illustrates the problem.
> !jxray-analysis-dup-strings.png|width=638,height=669!
> It turns out that a lot of duplicate strings come from the oozie's own code, 
> i.e. {{org.apache.oozie.*}}. In particular, the top data field wasting memory 
> is {{org.apache.oozie.StringBlob.string}} (wastes 2.6%, or ~160MB). From the 
> source code of {{StringBlob}} I see that it would be trivial to intern 
> (deduplicate) these strings by adding the call to {{String.intern()}} in the 
> constructor and a few other places. Similarly, various fields of 
> {{org.apache.oozie.WorkflowJobBean}} and {{WorkflowActionBean}} collectively 
> waste a lot of memory, and can be fixed in the same way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Moving Oozie to pull requests

2018-05-08 Thread Andras Piros 
Hi Geza,

+1 on using GitHub pull requests instead of patches uploaded to ReviewBoard
/ JIRA. PRs are the modern way of doing code reviews, integrating changes,
doing source code management in general.

This step will lower the barrier newcomers face when trying to contribute
for the first time, too.

Andras

On Tue, May 8, 2018 at 4:01 PM, Peter Cseh  wrote:

> Hi team Oozie!
>
> Many projects are using pull requests on Github instead of uploading
> patches to Jira.
> Based on my experience with those projects, pull requests are easier to
> manage and less error prone than the current way of doing commits in Oozie.
>
> I would like to migrate Oozie to use pull requests instead of patch files
> in the next quarter if the community is up for that change.
> I don't really see any downsides other than we'll have to resubmit some
> patches for old jiras, which we'll have to do anyways due to possible merge
> conflicts.
> The tooling and automation possibilities around pull requests will probably
> meet all our needs.
>
> I don't know if we'd need an official vote for a change like this or
> regular Jira is enough to track all the necessary changes. Let's see if
> there are any objections against the general idea before going too much
> into details. :)
>
> So... Any objections?
> gp
>
>
> --
> *Peter Cseh *| Software Engineer
> cloudera.com 
>
> [image: Cloudera] 
>
> [image: Cloudera on Twitter]  [image:
> Cloudera on Facebook]  [image: Cloudera
> on LinkedIn] 
> --
>

[jira] [Commented] (OOZIE-3219) Cannot compile with hadoop 3.1.0

2018-05-08 Thread Peter Cseh (JIRA) 

[ 
https://issues.apache.org/jira/browse/OOZIE-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467458#comment-16467458
 ] 

Peter Cseh commented on OOZIE-3219:
---

+1

> Cannot compile with hadoop 3.1.0
> 
>
> Key: OOZIE-3219
> URL: https://issues.apache.org/jira/browse/OOZIE-3219
> Project: Oozie
>  Issue Type: Bug
>  Components: core
>Affects Versions: 5.0.0
> Environment: {code:java}
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
> 2018-02-24T19:49:05Z)
> Maven home: /opt/maven/apache-maven-3.5.3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64", 
> family: "unix"{code}
> latest 5.0 release bits
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3219.00.patch, OOZIE-3219.002.patch
>
>
> command failure on the following, same happens with 3.0.0. Issue does not 
> appear with < 3.0
> {code:java}
> mvn clean install -DskipTests -Dhadoop.version=3.1.0{code}
> {code:java}
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] 
> /tmp/oozie-5.0.0/core/src/main/java/org/apache/oozie/util/db/FailingConnectionWrapper.java:[24,37]
>  package org.apache.directory.api.util does not exist
> [ERROR] 
> /tmp/oozie-5.0.0/core/src/main/java/org/apache/oozie/util/db/FailingConnectionWrapper.java:[352,41]
>  cannot find symbol
> symbol: variable Strings
> location: class 
> org.apache.oozie.util.db.FailingConnectionWrapper.OozieDmlStatementPredicate
> [INFO] 2 errors
> [INFO] -
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Oozie Main 5.0.0  SUCCESS [ 3.768 s]
> [INFO] Apache Oozie Client  SUCCESS [ 30.924 
> s]
> [INFO] Apache Oozie Share Lib Oozie ... SUCCESS [ 20.904 
> s]
> [INFO] Apache Oozie Share Lib HCatalog  SUCCESS [ 9.150 s]
> [INFO] Apache Oozie Share Lib Distcp .. SUCCESS [ 7.938 s]
> [INFO] Apache Oozie Core .. FAILURE [ 13.929 
> s]
> [INFO] Apache Oozie Share Lib Streaming ... SKIPPED
> [INFO] Apache Oozie Share Lib Pig . SKIPPED
> [INFO] Apache Oozie Share Lib Hive  SKIPPED
> [INFO] Apache Oozie Share Lib Hive 2 .. SKIPPED
> [INFO] Apache Oozie Share Lib Sqoop ... SKIPPED
> [INFO] Apache Oozie Examples .. SKIPPED
> [INFO] Apache Oozie Share Lib Spark ... SKIPPED
> [INFO] Apache Oozie Share Lib . SKIPPED
> [INFO] Apache Oozie Docs .. SKIPPED
> [INFO] Apache Oozie WebApp  SKIPPED
> [INFO] Apache Oozie Tools . SKIPPED
> [INFO] Apache Oozie MiniOozie . SKIPPED
> [INFO] Apache Oozie Server  SKIPPED
> [INFO] Apache Oozie Distro  SKIPPED
> [INFO] Apache Oozie ZooKeeper Security Tests 5.0.0  SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 01:28 min
> [INFO] Finished at: 2018-04-13T14:03:17Z
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile 
> (default-compile) on project oozie-core: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /tmp/oozie-5.0.0/core/src/main/java/org/apache/oozie/util/db/FailingConnectionWrapper.java:[24,37]
>  package org.apache.directory.api.util does not exist
> [ERROR] 
> /tmp/oozie-5.0.0/core/src/main/java/org/apache/oozie/util/db/FailingConnectionWrapper.java:[352,41]
>  cannot find symbol
> [ERROR] symbol: variable Strings
> [ERROR] location: class 
> org.apache.oozie.util.db.FailingConnectionWrapper.OozieDmlStatementPredicate
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [H

[jira] [Commented] (OOZIE-3227) Eliminate duplicated dependencies from distributed cache

2018-05-08 Thread Peter Cseh (JIRA) 

[ 
https://issues.apache.org/jira/browse/OOZIE-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467460#comment-16467460
 ] 

Peter Cseh commented on OOZIE-3227:
---

I see the value in this as it's almost impossible to remove all duplicates on 
the packaging level, especially with multiple supported component versions in 
play.

I've reviewed OOZIE-3219 so we can proceed with testing this.
Thanks for the contribution [~dionusos]!


> Eliminate duplicated dependencies from distributed cache
> 
>
> Key: OOZIE-3227
> URL: https://issues.apache.org/jira/browse/OOZIE-3227
> Project: Oozie
>  Issue Type: Sub-task
>  Components: core
>Reporter: Denes Bodo
>Assignee: Denes Bodo
>Priority: Major
>
> Using Hadoop 3 it is not allowed to have multiple dependencies with same file 
> names on the list of *mapreduce.job.cache.files*.
> The issue occurs when I have the same file name on multiple sharelib folders 
> and/or my application's lib folder. This can be avoided but not easy all the 
> time.
> I suggest to remove the duplicates from this list.
> A quick workaround for the source code in JavaActionExecutor is like:
> {code}
> removeDuplicatedDependencies(launcherJobConf, 
> "mapreduce.job.cache.files");
> removeDuplicatedDependencies(launcherJobConf, 
> "mapreduce.job.cache.archives");
> ..
> private void removeDuplicatedDependencies(JobConf conf, String key) {
> final Map nameToPath = new HashMap<>();
> StringBuilder uniqList = new StringBuilder();
> for(String dependency: conf.get(key).split(",")) {
> final String[] arr = dependency.split("/");
> final String dependencyName = arr[arr.length - 1];
> if(nameToPath.containsKey(dependencyName)) {
> LOG.warn(dependencyName + " [" + dependency + "] is already 
> defined in " + key + ". Skipping...");
> } else {
> nameToPath.put(dependencyName, dependency);
> uniqList.append(dependency).append(",");
> }
> }
> uniqList.setLength(uniqList.length() - 1);
> conf.set(key, uniqList.toString());
> }
> {code}
> Other way is to eliminate the deprecated 
> *org.apache.hadoop.filecache.DistributedCache*.
> I am going to have a deeper understanding how we should use distributed cache 
> and all the comments are welcome.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OOZIE-1624) Exclusion pattern for sharelib JARs

2018-05-08 Thread Peter Cseh (JIRA) 

[ 
https://issues.apache.org/jira/browse/OOZIE-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467456#comment-16467456
 ] 

Peter Cseh commented on OOZIE-1624:
---

I don't really see the value of a preconfigured blacklisted JAR pattern as 
there are almost an infinite way to define the equivalent of "oozie*jar" using 
regex. :) 
We should definitely log out every single jar we're removing though to avoid 
confusion about missing jars.

I'd prefer Rohini's take and filter against the full path -  excluding the 
sharelib root - as it's easy to just add a "*/" to the start of the pattern to 
exclude it from everywhere and it is more flexible than filtering just for 
filenames.



 

> Exclusion pattern for sharelib JARs
> ---
>
> Key: OOZIE-1624
> URL: https://issues.apache.org/jira/browse/OOZIE-1624
> Project: Oozie
>  Issue Type: Sub-task
>Affects Versions: 4.3.1
>Reporter: Purshotam Shah
>Assignee: Purshotam Shah
>Priority: Major
> Attachments: OOZIE-1624-V2.patch, OOZIE-1624-V3.patch, 
> OOZIE-1624-V4.patch, OOZIE-1624-v1.patch
>
>
> Sharelib may bring some jar which might conflict with user jars.
> Ex. Sharelib hive has json-2..jar, where as some of the user use-case 
> need higher version of json jar.
> He should be able to exclude sharelib json jar and bring his own version.
> 
> oozie.action.sharelib.for.hive.exclusion
> json-\*.jar|abc-*.jar
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Moving Oozie to pull requests

2018-05-08 Thread Peter Cseh 
Hi team Oozie!

Many projects are using pull requests on Github instead of uploading
patches to Jira.
Based on my experience with those projects, pull requests are easier to
manage and less error prone than the current way of doing commits in Oozie.

I would like to migrate Oozie to use pull requests instead of patch files
in the next quarter if the community is up for that change.
I don't really see any downsides other than we'll have to resubmit some
patches for old jiras, which we'll have to do anyways due to possible merge
conflicts.
The tooling and automation possibilities around pull requests will probably
meet all our needs.

I don't know if we'd need an official vote for a change like this or
regular Jira is enough to track all the necessary changes. Let's see if
there are any objections against the general idea before going too much
into details. :)

So... Any objections?
gp


-- 
*Peter Cseh *| Software Engineer
cloudera.com 

[image: Cloudera] 

[image: Cloudera on Twitter]  [image:
Cloudera on Facebook]  [image: Cloudera
on LinkedIn] 
--

[jira] [Created] (OOZIE-3246) Flaky test TestJMSJobEventListener#testConnectionDrop

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3246:
---

 Summary: Flaky test TestJMSJobEventListener#testConnectionDrop
 Key: OOZIE-3246
 URL: https://issues.apache.org/jira/browse/OOZIE-3246
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


The testcase TestJMSJobEventListener#testConnectionDrop occasionally fails with 
the following error:

{noformat}
junit.framework.AssertionFailedError: 
org.apache.activemq:type=Broker,brokerName=localhost
at 
org.apache.oozie.jms.TestJMSJobEventListener.testConnectionDrop(TestJMSJobEventListener.java:365)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OOZIE-3245) Flaky test TestCoordActionsKillXCommand#testActionKillCommandActionNumbers

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3245:
---

 Summary: Flaky test 
TestCoordActionsKillXCommand#testActionKillCommandActionNumbers
 Key: OOZIE-3245
 URL: https://issues.apache.org/jira/browse/OOZIE-3245
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


The testcase TestCoordActionsKillXCommand#testActionKillCommandActionNumbers 
occasionally fails with the following error:

{noformat}
junit.framework.AssertionFailedError: expected: but 
was:
at 
org.apache.oozie.command.coord.TestCoordActionsKillXCommand.testActionKillCommandActionNumbers(TestCoordActionsKillXCommand.java:96
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OOZIE-3244) Flaky test TestBundleChangeXCommand#testBundlePauseExtendMaterializesCoordinator

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3244:
---

 Summary: Flaky test 
TestBundleChangeXCommand#testBundlePauseExtendMaterializesCoordinator
 Key: OOZIE-3244
 URL: https://issues.apache.org/jira/browse/OOZIE-3244
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


The testcase 
TestBundleChangeXCommand#testBundlePauseExtendMaterializesCoordinator 
occasionally fails:

{noformat}
junit.framework.AssertionFailedError: expected: but was:
at 
org.apache.oozie.command.bundle.TestBundleChangeXCommand.testBundlePauseExtendMaterializesCoordinator(TestBundleChangeXCommand.java:244)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OOZIE-3243) Flaky test TestCoordActionsKillXCommand#testActionKillCommandDate

2018-05-08 Thread Peter Bacsko (JIRA) 

 [ 
https://issues.apache.org/jira/browse/OOZIE-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Bacsko updated OOZIE-3243:

Summary: Flaky test TestCoordActionsKillXCommand#testActionKillCommandDate  
(was: TestCoordActionsKillXCommand#testActionKillCommandDate)

> Flaky test TestCoordActionsKillXCommand#testActionKillCommandDate
> -
>
> Key: OOZIE-3243
> URL: https://issues.apache.org/jira/browse/OOZIE-3243
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Peter Bacsko
>Priority: Major
>
> The testcase TestCoordActionsKillXCommand#testActionKillCommandDate 
> occasionally fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError: expected: but was:
>   at 
> org.apache.oozie.command.coord.TestCoordActionsKillXCommand.testActionKillCommandDate(TestCoordActionsKillXCommand.java:131)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OOZIE-3243) TestCoordActionsKillXCommand#testActionKillCommandDate

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3243:
---

 Summary: TestCoordActionsKillXCommand#testActionKillCommandDate
 Key: OOZIE-3243
 URL: https://issues.apache.org/jira/browse/OOZIE-3243
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


The testcase TestCoordActionsKillXCommand#testActionKillCommandDate 
occasionally fails with the following error:

{noformat}
junit.framework.AssertionFailedError: expected: but was:
at 
org.apache.oozie.command.coord.TestCoordActionsKillXCommand.testActionKillCommandDate(TestCoordActionsKillXCommand.java:131)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OOZIE-3242) Flaky test TestXCommand#testXCommandLifecycleLockingFailingToLock

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3242:
---

 Summary: Flaky test 
TestXCommand#testXCommandLifecycleLockingFailingToLock
 Key: OOZIE-3242
 URL: https://issues.apache.org/jira/browse/OOZIE-3242
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


The test case TestXCommand#testXCommandLifecycleLockingFailingToLock 
occasionally fails with the following error:

{noformat}
junit.framework.AssertionFailedError
at 
org.apache.oozie.command.TestXCommand.testXCommandLifecycleLockingFailingToLock(TestXCommand.java:186)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OOZIE-3241) Flaky test TestRecoveryService#testCoordActionRecoveryServiceForWaitingRegisterPartition

2018-05-08 Thread Peter Bacsko (JIRA) 

 [ 
https://issues.apache.org/jira/browse/OOZIE-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Bacsko updated OOZIE-3241:

Attachment: OOZIE-3241.txt

> Flaky test 
> TestRecoveryService#testCoordActionRecoveryServiceForWaitingRegisterPartition
> 
>
> Key: OOZIE-3241
> URL: https://issues.apache.org/jira/browse/OOZIE-3241
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Peter Bacsko
>Priority: Major
> Attachments: OOZIE-3241.txt
>
>
> The test 
> TestRecoveryService#testCoordActionRecoveryServiceForWaitingRegisterPartition 
> occasionally fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError
>   at 
> org.apache.oozie.service.TestRecoveryService.testCoordActionRecoveryServiceForWaitingRegisterPartition(TestRecoveryService.java:506)
> {noformat}
> Errors in the test:
> {noformat}
> [jndiProperties=java.naming.factory.initial#org.apache.activemq.jndi.ActiveMQInitialContextFactory;java.naming.provider.url#vm://localhost?broker.persistent=falseconnectionFactoryNames#ConnectionFactory]]
> javax.jms.JMSException: Could not create Transport. Reason: 
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:type=Broker,brokerName=localhost
>   at 
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
>   at 
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:332)
>   at 
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:345)
>   at 
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:303)
>   at 
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:243)
>   at 
> org.apache.oozie.jms.DefaultConnectionContext.createConnection(DefaultConnectionContext.java:53)
>   at 
> org.apache.oozie.service.JMSAccessorService.createConnectionContext(JMSAccessorService.java:264)
>   at 
> org.apache.oozie.service.JMSAccessorService.registerForNotification(JMSAccessorService.java:110)
>   at 
> org.apache.oozie.service.HCatAccessorService.registerForNotification(HCatAccessorService.java:236)
>   at 
> org.apache.oozie.dependency.HCatURIHandler.registerForNotification(HCatURIHandler.java:119)
>   at 
> org.apache.oozie.command.coord.CoordPushDependencyCheckXCommand.registerForNotification(CoordPushDependencyCheckXCommand.java:314)
>   at 
> org.apache.oozie.command.coord.CoordPushDependencyCheckXCommand.execute(CoordPushDependencyCheckXCommand.java:174)
>   at 
> org.apache.oozie.command.coord.CoordPushDependencyCheckXCommand.execute(CoordPushDependencyCheckXCommand.java:62)
>   at org.apache.oozie.command.XCommand.call(XCommand.java:290)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> org.apache.oozie.service.CallableQueueService$CallableWrapper.run(CallableQueueService.java:181)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:type=Broker,brokerName=localhost
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:408)
>   at 
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
>   at 
> org.apache.activemq.broker.BrokerService.startManagementContext(BrokerService.java:2581)
>   at 
> org.apache.activemq.broker.BrokerService.start(BrokerService.java:606)
>   at 
> org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:127)
>   at 
> org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:56)
>   at 
> org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:69)
>   at 
> org.apache.activemq.ActiveMQConnectio

[jira] [Created] (OOZIE-3241) Flaky test TestRecoveryService#testCoordActionRecoveryServiceForWaitingRegisterPartition

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3241:
---

 Summary: Flaky test 
TestRecoveryService#testCoordActionRecoveryServiceForWaitingRegisterPartition
 Key: OOZIE-3241
 URL: https://issues.apache.org/jira/browse/OOZIE-3241
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


The test 
TestRecoveryService#testCoordActionRecoveryServiceForWaitingRegisterPartition 
occasionally fails with the following error:

{noformat}
junit.framework.AssertionFailedError
at 
org.apache.oozie.service.TestRecoveryService.testCoordActionRecoveryServiceForWaitingRegisterPartition(TestRecoveryService.java:506)
{noformat}

Errors in the test:

{noformat}
[jndiProperties=java.naming.factory.initial#org.apache.activemq.jndi.ActiveMQInitialContextFactory;java.naming.provider.url#vm://localhost?broker.persistent=falseconnectionFactoryNames#ConnectionFactory]]
javax.jms.JMSException: Could not create Transport. Reason: 
javax.management.InstanceAlreadyExistsException: 
org.apache.activemq:type=Broker,brokerName=localhost
at 
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at 
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:332)
at 
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:345)
at 
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:303)
at 
org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:243)
at 
org.apache.oozie.jms.DefaultConnectionContext.createConnection(DefaultConnectionContext.java:53)
at 
org.apache.oozie.service.JMSAccessorService.createConnectionContext(JMSAccessorService.java:264)
at 
org.apache.oozie.service.JMSAccessorService.registerForNotification(JMSAccessorService.java:110)
at 
org.apache.oozie.service.HCatAccessorService.registerForNotification(HCatAccessorService.java:236)
at 
org.apache.oozie.dependency.HCatURIHandler.registerForNotification(HCatURIHandler.java:119)
at 
org.apache.oozie.command.coord.CoordPushDependencyCheckXCommand.registerForNotification(CoordPushDependencyCheckXCommand.java:314)
at 
org.apache.oozie.command.coord.CoordPushDependencyCheckXCommand.execute(CoordPushDependencyCheckXCommand.java:174)
at 
org.apache.oozie.command.coord.CoordPushDependencyCheckXCommand.execute(CoordPushDependencyCheckXCommand.java:62)
at org.apache.oozie.command.XCommand.call(XCommand.java:290)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.oozie.service.CallableQueueService$CallableWrapper.run(CallableQueueService.java:181)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.management.InstanceAlreadyExistsException: 
org.apache.activemq:type=Broker,brokerName=localhost
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at 
org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:408)
at 
org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
at 
org.apache.activemq.broker.BrokerService.startManagementContext(BrokerService.java:2581)
at 
org.apache.activemq.broker.BrokerService.start(BrokerService.java:606)
at 
org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:127)
at 
org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:56)
at 
org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:69)
at 
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:330)
... 17 more
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OOZIE-3240) Flaky test TestJMSAccessorService#testConnectionRetry

2018-05-08 Thread Peter Bacsko (JIRA) 

 [ 
https://issues.apache.org/jira/browse/OOZIE-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Bacsko updated OOZIE-3240:

Attachment: OOZIE-3240.txt

> Flaky test TestJMSAccessorService#testConnectionRetry
> -
>
> Key: OOZIE-3240
> URL: https://issues.apache.org/jira/browse/OOZIE-3240
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Peter Bacsko
>Priority: Major
> Attachments: OOZIE-3240.txt
>
>
> The test TestJMSAccessorService#testConnectionRetry failed with the following 
> errors in the log:
> {noformat}
> junit.framework.AssertionFailedError
>   at 
> org.apache.oozie.service.TestJMSAccessorService.testConnectionRetry(TestJMSAccessorService.java:183)
> {noformat}
> {noformat}
> [jndiProperties=java.naming.factory.initial#org.apache.activemq.jndi.ActiveMQInitialContextFactory;java.naming.provider.url#tcp://localhost:39362;connectionFactoryNames#ConnectionFactory]]
> javax.jms.JMSException: Could not connect to broker URL: 
> tcp://localhost:39362. Reason: java.net.ConnectException: Connection refused 
> (Connection refused)
>   at 
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
>   at 
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:373)
>   at 
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:303)
>   at 
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:243)
>   at 
> org.apache.oozie.jms.DefaultConnectionContext.createConnection(DefaultConnectionContext.java:53)
>   at 
> org.apache.oozie.service.JMSAccessorService.createConnectionContext(JMSAccessorService.java:264)
>   at 
> org.apache.oozie.service.JMSAccessorService.registerForNotification(JMSAccessorService.java:110)
>   at 
> org.apache.oozie.service.TestJMSAccessorService.testConnectionRetry(TestJMSAccessorService.java:173)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at org.junit.runners.Suite.runChild(Suite.java:127)
>   at org.junit.runners.Suite.runChild(Suite.java:26)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at org.junit.runners.Suite.runChild(Suite.java:127)
>   at org.junit.runners.Suite.runChild(Suite.java:26)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at 
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:410)
>   at 
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
>   at 
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:367)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junitcore.pc.ParallelComputerBuilder$PC$1.run(ParallelComputerBuilder.java:593)
>   at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
>   at 
> org.apache.maven.surefire.junitcore.JUn

[jira] [Created] (OOZIE-3240) Flaky test TestJMSAccessorService#testConnectionRetry

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3240:
---

 Summary: Flaky test TestJMSAccessorService#testConnectionRetry
 Key: OOZIE-3240
 URL: https://issues.apache.org/jira/browse/OOZIE-3240
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


The test TestJMSAccessorService#testConnectionRetry failed with the following 
errors in the log:

{noformat}
junit.framework.AssertionFailedError
at 
org.apache.oozie.service.TestJMSAccessorService.testConnectionRetry(TestJMSAccessorService.java:183)
{noformat}


{noformat}
[jndiProperties=java.naming.factory.initial#org.apache.activemq.jndi.ActiveMQInitialContextFactory;java.naming.provider.url#tcp://localhost:39362;connectionFactoryNames#ConnectionFactory]]
javax.jms.JMSException: Could not connect to broker URL: tcp://localhost:39362. 
Reason: java.net.ConnectException: Connection refused (Connection refused)
at 
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at 
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:373)
at 
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:303)
at 
org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:243)
at 
org.apache.oozie.jms.DefaultConnectionContext.createConnection(DefaultConnectionContext.java:53)
at 
org.apache.oozie.service.JMSAccessorService.createConnectionContext(JMSAccessorService.java:264)
at 
org.apache.oozie.service.JMSAccessorService.registerForNotification(JMSAccessorService.java:110)
at 
org.apache.oozie.service.TestJMSAccessorService.testConnectionRetry(TestJMSAccessorService.java:173)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at 
org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:410)
at 
org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
at 
org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:367)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junitcore.pc.ParallelComputerBuilder$PC$1.run(ParallelComputerBuilder.java:593)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:159)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:373)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSui

[jira] [Created] (OOZIE-3239) Flaky test TestJMSAccessorService#testConnectionRetryExceptionListener

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3239:
---

 Summary: Flaky test 
TestJMSAccessorService#testConnectionRetryExceptionListener
 Key: OOZIE-3239
 URL: https://issues.apache.org/jira/browse/OOZIE-3239
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


TestJMSAccessorService#testConnectionRetryExceptionListener occasionally fails 
with the following error:

{noformat}
javax.management.InstanceAlreadyExistsException: 
org.apache.activemq:type=Broker,brokerName=localhost
at 
org.apache.oozie.service.TestJMSAccessorService.testConnectionRetryExceptionListener(TestJMSAccessorService.java:213)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OOZIE-3238) Flaky test TestStatusTransitService#testBundleStatusTransitWithLock

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3238:
---

 Summary: Flaky test 
TestStatusTransitService#testBundleStatusTransitWithLock
 Key: OOZIE-3238
 URL: https://issues.apache.org/jira/browse/OOZIE-3238
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


TestStatusTransitService#testBundleStatusTransitWithLock occasionally fails 
with the following message:

{noformat}
junit.framework.AssertionFailedError: expected: but 
was:
at 
org.apache.oozie.service.TestStatusTransitService.testBundleStatusTransitWithLock(TestStatusTransitService.java:1593)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OOZIE-3237) Flaky test TestZKLocksService#testWriteReadLockThreads

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3237:
---

 Summary: Flaky test TestZKLocksService#testWriteReadLockThreads
 Key: OOZIE-3237
 URL: https://issues.apache.org/jira/browse/OOZIE-3237
 Project: Oozie
  Issue Type: Sub-task
Reporter: Peter Bacsko


The test TestZKLocksService#testWriteReadLockThreads failed with this error:

{noformat}
junit.framework.ComparisonFailure: expected: but 
was:
at 
org.apache.oozie.service.TestZKLocksService.checkWriteReadLock(TestZKLocksService.java:431)
at 
org.apache.oozie.service.TestZKLocksService.testWriteReadLockThreads(TestZKLocksService.java:396)
{noformat}

https://builds.apache.org/job/PreCommit-OOZIE-Build/516/consoleFull



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OOZIE-3236) Flaky test TestHiveActionExecutor#testHiveAction

2018-05-08 Thread Peter Bacsko (JIRA) 
Peter Bacsko created OOZIE-3236:
---

 Summary: Flaky test TestHiveActionExecutor#testHiveAction
 Key: OOZIE-3236
 URL: https://issues.apache.org/jira/browse/OOZIE-3236
 Project: Oozie
  Issue Type: Sub-task
  Components: action, tests
Reporter: Peter Bacsko
 Attachments: OOZIE-3236.txt

The test TestHiveActionExecutor#testHiveAction failed with this error:

{noformat}
junit.framework.AssertionFailedError: YARN App state for app 
application_1525471867439_0002 expected: but was:
at 
org.apache.oozie.action.hadoop.TestHiveActionExecutor.testHiveAction(TestHiveActionExecutor.java:158)
{noformat}

https://builds.apache.org/job/PreCommit-OOZIE-Build/516/testReport/junit/org.apache.oozie.action.hadoop/TestHiveActionExecutor/testHiveAction/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OOZIE-3236) Flaky test TestHiveActionExecutor#testHiveAction

2018-05-08 Thread Peter Bacsko (JIRA) 

 [ 
https://issues.apache.org/jira/browse/OOZIE-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Bacsko updated OOZIE-3236:

Attachment: OOZIE-3236.txt

> Flaky test TestHiveActionExecutor#testHiveAction
> 
>
> Key: OOZIE-3236
> URL: https://issues.apache.org/jira/browse/OOZIE-3236
> Project: Oozie
>  Issue Type: Sub-task
>  Components: action, tests
>Reporter: Peter Bacsko
>Priority: Major
> Attachments: OOZIE-3236.txt
>
>
> The test TestHiveActionExecutor#testHiveAction failed with this error:
> {noformat}
> junit.framework.AssertionFailedError: YARN App state for app 
> application_1525471867439_0002 expected: but was:
>   at 
> org.apache.oozie.action.hadoop.TestHiveActionExecutor.testHiveAction(TestHiveActionExecutor.java:158)
> {noformat}
> https://builds.apache.org/job/PreCommit-OOZIE-Build/516/testReport/junit/org.apache.oozie.action.hadoop/TestHiveActionExecutor/testHiveAction/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)