[jira] [Commented] (OOZIE-2617) Read properties files in action configurations

2016-09-12 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2617:


+1

> Read properties files in action configurations
> --
>
> Key: OOZIE-2617
> URL: https://issues.apache.org/jira/browse/OOZIE-2617
> Project: Oozie
>  Issue Type: Improvement
>  Components: core
>Affects Versions: trunk
>Reporter: Taklon Stephen Wu
>  Labels: patch
> Fix For: 4.3.0
>
> Attachments: OOZIE-2617-1.patch, OOZIE-2617-2.patch, 
> OOZIE-2617-3.patch
>
>
> Current logic of acton configuration only READ xml files within Oozie action 
> directory, but for pig and other applications, properties files are supported 
> and may be default configuration file format. To simplify the logic of 
> reusing these properties files when using Oozie with them, we add properties 
> file reading in action conf.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2583) oozie throws EL Exception when reference variable name containing dot

2016-09-13 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2583:


+1

> oozie throws EL Exception when reference variable name containing dot
> -
>
> Key: OOZIE-2583
> URL: https://issues.apache.org/jira/browse/OOZIE-2583
> Project: Oozie
>  Issue Type: Bug
>  Components: core
>Affects Versions: 4.3.0
>Reporter: zhixun he
>Assignee: Abhishek Bafna
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: OOZIE-2583-00.patch, OOZIE-2583-01.patch, 
> OOZIE-2583-02.patch, OOZIE-2583-03.patch, OOZIE-2583-04.patch, 
> OOZIE-2583-04.patch
>
>
> TestOozieRegression.test_BundleApppath test case failed due to following 
> error:
> {noformat}
> 2016-06-21 06:34:02,116 WARN ActionStartXCommand:523 - SERVER[l] 
> USER[hrt_qa] GROUP[-] TOKEN[] APP[test_4591177_1] 
> JOB[075-160621052006550-oozie-oozi-W] 
> ACTION[075-160621052006550-oozie-oozi-W@subwf] EL Exception in 
> ActionStartXCommand 
> . javax.servlet.jsp.el.EL Exception : variable [oozie] cannot be resolved
> . at 
> org.apache.oozie.util.ELEvaluator$Context.resolveVariable(ELEvaluator.java:107)
> . at org.apache.commons.el.NamedValue.evaluate(NamedValue.java:124)
> . at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:140)
> . at 
> org.apache.commons.el.ExpressionString.evaluate(ExpressionString.java:114)
> . at 
> org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:274)
> . at 
> org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:190)
> . at org.apache.oozie.util.ELEvaluator.evaluate(ELEvaluator.java:204)
> . at 
> org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:193)
> . at 
> org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:63)
> . at org.apache.oozie.command.XCommand.call(XCommand.java:287)
> . at 
> org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:331)
> . at 
> org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:260)
> . at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> . at 
> org.apache.oozie.service.CallableQueueService$CallableWrapper.run(CallableQueueService.java:178)
> . at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> . at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> . at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2668) Status update and recovery problems when coord action and its children not in sync

2016-09-13 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2668:


Please add the test case.

> Status update and recovery problems when coord action and its children not in 
> sync
> --
>
> Key: OOZIE-2668
> URL: https://issues.apache.org/jira/browse/OOZIE-2668
> Project: Oozie
>  Issue Type: Bug
>Reporter: Satish Subhashrao Saley
>Assignee: Satish Subhashrao Saley
> Attachments: OOZIE-2668-1.patch
>
>
> In cases where workflow is already in terminal status (except failed) but the 
> coord action is not yet updated and still running, following will happen if a 
> kill command is issued on the coord job: 
> Kill on Coordjob will make the kill on coordaction pending until the children 
> are also killed. However, as the wf in terminal state (except failed), the wf 
> will not be killed and preverifycondition will fail. The wf doesn't update 
> its parent and hence the coordaction kill will still be pending. Two 
> problems: Status transit service will not resolve the state of this coord job 
> as some the actions are still pending Recovery service will try to recover 
> this killed coord action and keep on reissuing the kill command.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2652) Skip trash while deleting hive table partition

2016-09-13 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2652:


Look like some issue with the patch, Patch failed to apply. 
As multiple exceptions are executing same statement, Can you change it to or 
condition like. 
{code}
(SecurityException  | NoSuchMethodException e)
{code}

> Skip trash while deleting hive table partition
> --
>
> Key: OOZIE-2652
> URL: https://issues.apache.org/jira/browse/OOZIE-2652
> Project: Oozie
>  Issue Type: Bug
>Reporter: Satish Subhashrao Saley
>Assignee: Satish Subhashrao Saley
> Attachments: OOZIE-2652-1.patch
>
>
> Currently, when we delete a partition in the work flow, the data persists in 
> trash and does not get purged. This takes up namespaces.
> {code}
>  
> ${jobTracker}
> ${oozieNameNode}
> 
> 
> 
> {code}
> Solution: User will pass on "skip-trash" option. Accordingly, Oozie will call 
> appropriate hcat api. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (OOZIE-2652) Skip trash while deleting hive table partition

2016-09-13 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma edited comment on OOZIE-2652 at 9/13/16 7:20 PM:
-

Look like some issue with the patch, Patch failed to apply. 
As multiple exceptions are executing same statement, Can you change it to or 
condition like. 
{code}
(SecurityException  | NoSuchMethodException e)
{code}

Can you also add test case?


was (Author: jaydeepvishwakarma):
Look like some issue with the patch, Patch failed to apply. 
As multiple exceptions are executing same statement, Can you change it to or 
condition like. 
{code}
(SecurityException  | NoSuchMethodException e)
{code}

> Skip trash while deleting hive table partition
> --
>
> Key: OOZIE-2652
> URL: https://issues.apache.org/jira/browse/OOZIE-2652
> Project: Oozie
>  Issue Type: Bug
>Reporter: Satish Subhashrao Saley
>Assignee: Satish Subhashrao Saley
> Attachments: OOZIE-2652-1.patch
>
>
> Currently, when we delete a partition in the work flow, the data persists in 
> trash and does not get purged. This takes up namespaces.
> {code}
>  
> ${jobTracker}
> ${oozieNameNode}
> 
> 
> 
> {code}
> Solution: User will pass on "skip-trash" option. Accordingly, Oozie will call 
> appropriate hcat api. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2488) Upgrade to latest OpenJPA version

2016-09-14 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2488:


+1

> Upgrade to latest OpenJPA version
> -
>
> Key: OOZIE-2488
> URL: https://issues.apache.org/jira/browse/OOZIE-2488
> Project: Oozie
>  Issue Type: Improvement
>  Components: core
>Reporter: Robert Kanter
>Assignee: Abhishek Bafna
> Fix For: 4.3.0
>
> Attachments: OOZIE-2488-00.patch
>
>
> Oozie is currently using OpenJPA 2.2.2, which is from April 2013.  Version 
> 2.3.0 is from Nov 2013, but there was a recent 2.4.1 release in Feb 2016 
> (that's a long gap!).  Given that this is a critical dependency, it might be 
> a good idea to take a look at the chnagelog, do some testing, and update the 
> dependency.  I'm sure there's lots of bug fixes that would be great to have.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2657) Clean up redundant access modifiers from oozie interfaces

2016-09-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2657:


+1

> Clean up redundant access modifiers from oozie interfaces
> -
>
> Key: OOZIE-2657
> URL: https://issues.apache.org/jira/browse/OOZIE-2657
> Project: Oozie
>  Issue Type: Bug
>  Components: core
>Reporter: Abhishek Bafna
>Assignee: Abhishek Bafna
>Priority: Minor
>  Labels: code-cleanup
> Fix For: 4.3.0
>
> Attachments: OOZIE-2657-00-amend.patch, OOZIE-2657-00.patch
>
>
> By default java {{interface}} fields are {{public static final}}. Some of the 
> Oozie interface still explicitly declare these redundant access modifier. I 
> think we can clean it.
> Similarly, methods declared in the interface are {{public}}. This redundant 
> declaration can be cleaned up.
> {code}
> public interface RestConstants {
> public static final String VERSIONS = "versions";
> public static final String JOB = "job";
> ...
> }
> public interface JsonTags {
> public static final String OOZIE_SAFE_MODE = "safeMode"; //Applicable for 
> V0 only
> public static final String OOZIE_SYSTEM_MODE = "systemMode";
> ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1978) Forkjoin validation code is ridiculously slow in some cases

2016-09-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1978:


+1, LGTM

> Forkjoin validation code is ridiculously slow in some cases
> ---
>
> Key: OOZIE-1978
> URL: https://issues.apache.org/jira/browse/OOZIE-1978
> Project: Oozie
>  Issue Type: Bug
>  Components: core
>Affects Versions: trunk, 4.0.1
>Reporter: Robert Kanter
>Assignee: Peter Bacsko
> Fix For: 4.3.0
>
> Attachments: OOZIE-1978-001.patch, OOZIE-1978-002.patch, 
> OOZIE-1978-002.patch, OOZIE-1978-003.patch, OOZIE-1978-004.patch, 
> OOZIE-1978-005.patch, OOZIE-1978-006.patch, OOZIE-1978_wip.001.patch, 
> workflow.xml
>
>
> We've had a few users who have run into problems where submitting a workflow 
> appears to hang (in the case of a subworkflow, it's similar but stuck in 
> PREP).  It turns out that if you wait long enough, it will actually go 
> through and the workflow will run normally.  The problem is that the forkjoin 
> validation code is taking a really long time.
> The attached example has a series of 20 forks where each fork has 6 actions 
> (it's based on an actual workflow, but all of the names were changed and the 
> actions were all replaced by simple shell actions).  One of our support guys 
> said it took 1-2 hours , but on my computer it was taking {color:red}*15+ 
> hours*{color} (I had to cancel it)
> While this example doesn't have any nested forks, those can also take a long 
> time too.
> It's easy to verify that it's the forkjoin validation code that's taking so 
> long by looking at a jstack of the Oozie server and seeing deep recursive 
> calls to 
> {{org.apache.oozie.workflow.lite.LiteWorkflowAppParser.validateForkJoin}}.  I 
> also noticed a lot of sitting around in calls LinkedList.contains.  
> I think we have 3 options:
> # See if we can make the existing code faster somehow.  Perhaps there's a way 
> to parallelize it?  Maybe there's some redundant checking that we can 
> identify and skip? Change some data structures? etc
> # See if we can write a new way to do this validation.  I had originally 
> completely rewritten this code a while ago, and we've since made a few fixes 
> to catch edge cases and things.  Perhaps it needs another rewrite?
> # Try to identify when it's taking a long time and at least let the user know 
> what's happening or something.  Right now, it just appears that the Oozie CLI 
> has hung and the job doesn't show up in the Oozie server.  Most users aren't 
> going to wait more than a minute or two.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2657) Clean up redundant access modifiers from oozie interfaces

2016-09-19 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2657:


[~rkanter], 
The changes are in {{interface}} and it does not change so frequently, except 
the {{interface}} with contains only {{constants}}. 
Also I believe removing redundant access modifier will make any backward 
compatibility issue, perhaps you meant something else?
It is common knowledge in case of interface that everything is public (there is 
no point in putting a private member, because you are actually establishing an 
interface) and and all assignments are final, because no instance it is also at 
class level. Java's native supplied JDK interfaces don't put these modifiers. 
So if you want to follow best practices, that is what you would follow.


> Clean up redundant access modifiers from oozie interfaces
> -
>
> Key: OOZIE-2657
> URL: https://issues.apache.org/jira/browse/OOZIE-2657
> Project: Oozie
>  Issue Type: Bug
>  Components: core
>Reporter: Abhishek Bafna
>Assignee: Abhishek Bafna
>Priority: Minor
>  Labels: code-cleanup
> Fix For: 4.3.0
>
> Attachments: OOZIE-2657-00-amend.patch, OOZIE-2657-00.patch
>
>
> By default java {{interface}} fields are {{public static final}}. Some of the 
> Oozie interface still explicitly declare these redundant access modifier. I 
> think we can clean it.
> Similarly, methods declared in the interface are {{public}}. This redundant 
> declaration can be cleaned up.
> {code}
> public interface RestConstants {
> public static final String VERSIONS = "versions";
> public static final String JOB = "job";
> ...
> }
> public interface JsonTags {
> public static final String OOZIE_SAFE_MODE = "safeMode"; //Applicable for 
> V0 only
> public static final String OOZIE_SYSTEM_MODE = "systemMode";
> ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2622) ExtJS 2.2 in no available

2016-09-19 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2622:


[~rkanter], I am not sure if we can use the same code from somewhere else also, 
I have gone through License https://www.sencha.com/legal/GPL/ , unable to 
interpret. I would recommend you to go through license. We should be careful 
before putting the link. 
Oozie Monitoring UI is one of most useful feature what oozie user use. If we 
are not able to use it, We have to find some alternate solution. 

> ExtJS 2.2 in no available
> -
>
> Key: OOZIE-2622
> URL: https://issues.apache.org/jira/browse/OOZIE-2622
> Project: Oozie
>  Issue Type: Bug
>Affects Versions: 4.2.0
>Reporter: Sergey Svinarchuk
>Priority: Blocker
> Fix For: 4.3.0
>
>
> ExtJS 2.2 is no longer available by link from Oozie docs - 
> http://dev.sencha.com/deploy/ext-2.2.zip 
> (http://oozie.apache.org/docs/4.2.0/DG_QuickStart.html)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2622) ExtJS 2.2 is no longer available

2016-09-23 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2622:


I watched "oozie on hue" video. I am really impressed with it.  Developing 
something again instead of using hue would be good option.  We should retry to 
integrate it.

> ExtJS 2.2 is no longer available
> 
>
> Key: OOZIE-2622
> URL: https://issues.apache.org/jira/browse/OOZIE-2622
> Project: Oozie
>  Issue Type: Bug
>Affects Versions: 4.2.0
>Reporter: Sergey Svinarchuk
>Priority: Blocker
> Fix For: 4.3.0
>
>
> ExtJS 2.2 is no longer available by link from Oozie docs - 
> http://dev.sencha.com/deploy/ext-2.2.zip 
> (http://oozie.apache.org/docs/4.2.0/DG_QuickStart.html)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2622) ExtJS 2.2 is no longer available

2016-09-29 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2622:


+1

> ExtJS 2.2 is no longer available
> 
>
> Key: OOZIE-2622
> URL: https://issues.apache.org/jira/browse/OOZIE-2622
> Project: Oozie
>  Issue Type: Bug
>Affects Versions: 4.2.0
>Reporter: Sergey Svinarchuk
>Assignee: Robert Kanter
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: OOZIE-2622.001.patch
>
>
> ExtJS 2.2 is no longer available by link from Oozie docs - 
> http://dev.sencha.com/deploy/ext-2.2.zip 
> (http://oozie.apache.org/docs/4.2.0/DG_QuickStart.html)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OOZIE-2719) Test case failure

2016-10-28 Thread Jaydeep Vishwakarma (JIRA)
Jaydeep Vishwakarma created OOZIE-2719:
--

 Summary: Test case failure
 Key: OOZIE-2719
 URL: https://issues.apache.org/jira/browse/OOZIE-2719
 Project: Oozie
  Issue Type: Bug
  Components: core
Reporter: Jaydeep Vishwakarma


The test case {{TestLiteWorkflowAppParser.testForkJoinMismatch}} is failing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2719) Test case failure

2016-11-02 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2719:


+1 , Verified

> Test case failure
> -
>
> Key: OOZIE-2719
> URL: https://issues.apache.org/jira/browse/OOZIE-2719
> Project: Oozie
>  Issue Type: Bug
>  Components: core
>Reporter: Jaydeep Vishwakarma
>Assignee: Abhishek Bafna
> Fix For: 4.3.0
>
> Attachments: OOZIE-2719.patch
>
>
> The test case {{TestLiteWorkflowAppParser.testForkJoinMismatch}} is failing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2719) Test case failure

2016-11-02 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2719:


committed to master

> Test case failure
> -
>
> Key: OOZIE-2719
> URL: https://issues.apache.org/jira/browse/OOZIE-2719
> Project: Oozie
>  Issue Type: Bug
>  Components: core
>Reporter: Jaydeep Vishwakarma
>Assignee: Abhishek Bafna
> Fix For: 4.3.0
>
> Attachments: OOZIE-2719.patch
>
>
> The test case {{TestLiteWorkflowAppParser.testForkJoinMismatch}} is failing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2317) Figure out what to do about Tomcat 6 End of Life

2016-11-10 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2317:


[~rkanter] +1 from my side. No point to keep tomcat in with oozie. 

> Figure out what to do about Tomcat 6 End of Life
> 
>
> Key: OOZIE-2317
> URL: https://issues.apache.org/jira/browse/OOZIE-2317
> Project: Oozie
>  Issue Type: Bug
>  Components: core
>Affects Versions: trunk
>Reporter: Robert Kanter
>
> [Tomcat 6 will be end of life on Dec 31 
> 2016.|https://tomcat.apache.org/tomcat-60-eol.html]
> Even though that's a quite a while from now, it's best to stay ahead of 
> things, so it would be good if we looked into a plan for this.  
> Here are some options:
> # Upgrade to Tomcat 7
> # Upgrade to Tomcat 8
> # Switch to embedded Jetty 9
> I imagine upgrading to Tomcat 7/8 would be the easiest solution.  I haven't 
> looked into it much, but I imagine the build and deploy process could remain 
> relatively the same; though we'd probably have to tweak some config files and 
> things.  As for which version, Tomcat has [this 
> page|https://tomcat.apache.org/whichversion.html] to help.
> Switching to embedded Jetty 9 would require changing the build and deploy 
> process, though that might be a good thing given how that can be 
> complicated/confusing for users.  And I know Tomcat makes things difficult 
> for our packaging team in Cloudera.  Many other Hadoop projects use embedded 
> Jetty as well.  We do know that Oozie runs properly in Jetty because our unit 
> tests use Jetty.
> As part of this JIRA, the assignee should probably look into more specific 
> pros/cons of the options and we should all reach a consensus before moving 
> forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2225) Add wild card filter for gathering jobs

2016-11-17 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2225:


[~pbacsko] you do not need condition statement in following code. 
{code}
+if (!isEnabled) {
+isEnabled = true;
+}
{code}

> Add wild card filter for gathering jobs
> ---
>
> Key: OOZIE-2225
> URL: https://issues.apache.org/jira/browse/OOZIE-2225
> Project: Oozie
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 4.1.0
>Reporter: Sai Chirravuri
>Assignee: Peter Bacsko
> Fix For: trunk
>
> Attachments: OOZIE-2225-001.patch, OOZIE-2225-002.patch, 
> OOZIE-2225-003.patch, OOZIE-2225-004.patch, OOZIE-2225-005.patch, 
> OOZIE-2225-007.patch, OOZIE-2225-008.patch, OOZIE-2225-009.patch, 
> OOZIE-2225-010.patch, OOZIE-2225-amend-001.patch, OOZIE-2225-amend-002.patch
>
>
> Oozie currently supports name, user, group, status, frequency and unit as 
> filter params.
> Add wild card param that matches partially with name/user or complete match 
> with ID



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2225) Add wild card filter for gathering jobs

2016-11-17 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2225:


[~abhishekbafna], I did not mentioned isEnabled is not required. The condition 
statement is useless. 

{code}
if(false) {
true
}
vs
true
{code}

Why do you need to check boolean when you any how going to make it true.

> Add wild card filter for gathering jobs
> ---
>
> Key: OOZIE-2225
> URL: https://issues.apache.org/jira/browse/OOZIE-2225
> Project: Oozie
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 4.1.0
>Reporter: Sai Chirravuri
>Assignee: Peter Bacsko
> Fix For: trunk
>
> Attachments: OOZIE-2225-001.patch, OOZIE-2225-002.patch, 
> OOZIE-2225-003.patch, OOZIE-2225-004.patch, OOZIE-2225-005.patch, 
> OOZIE-2225-007.patch, OOZIE-2225-008.patch, OOZIE-2225-009.patch, 
> OOZIE-2225-010.patch, OOZIE-2225-amend-001.patch, OOZIE-2225-amend-002.patch
>
>
> Oozie currently supports name, user, group, status, frequency and unit as 
> filter params.
> Add wild card param that matches partially with name/user or complete match 
> with ID



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2690) OOZIE NPE while executing kill()

2016-11-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2690:


+1

> OOZIE NPE while executing kill()
> 
>
> Key: OOZIE-2690
> URL: https://issues.apache.org/jira/browse/OOZIE-2690
> Project: Oozie
>  Issue Type: Bug
>Reporter: Cheng Xu
>Assignee: Abhishek Bafna
> Fix For: 5.0.0
>
> Attachments: OOZIE-2690-00.patch
>
>
> ION[027-160917110703953-oozie-oozi-W@java2] Exception while executing 
> kill(). Error Code [NullPointerException], Message[NullPointerException: null]
> org.apache.oozie.action.ActionExecutorException: NullPointerException: null
> at 
> org.apache.oozie.action.ActionExecutor.convertException(ActionExecutor.java:446)
> at 
> org.apache.oozie.action.hadoop.JavaActionExecutor.kill(JavaActionExecutor.java:1632)
> at 
> org.apache.oozie.command.wf.ActionKillXCommand.execute(ActionKillXCommand.java:146)
> at 
> org.apache.oozie.command.wf.ActionKillXCommand.execute(ActionKillXCommand.java:62)
> at org.apache.oozie.command.XCommand.call(XCommand.java:287)
> at 
> org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:331)
> at 
> org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:260)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.oozie.service.CallableQueueService$CallableWrapper.run(CallableQueueService.java:178)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.apache.hadoop.mapreduce.TypeConverter.toYarn(TypeConverter.java:79)
> at 
> org.apache.hadoop.mapred.ClientServiceDelegate.(ClientServiceDelegate.java:120)
> at org.apache.hadoop.mapred.ClientCache.getClient(ClientCache.java:68)
> at org.apache.hadoop.mapred.YARNRunner.getJobStatus(YARNRunner.java:573)
> at org.apache.hadoop.mapreduce.Cluster.getJob(Cluster.java:184)
> at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:601)
> at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:599)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
> at 
> org.apache.hadoop.mapred.JobClient.getJobUsingCluster(JobClient.java:599)
> at org.apache.hadoop.mapred.JobClient.getJobInner(JobClient.java:609)
> at org.apache.hadoop.mapred.JobClient.getJob(JobClient.java:639)
> at 
> org.apache.oozie.action.hadoop.JavaActionExecutor.getJobClientWithRetries(JavaActionExecutor.java:1432)
> at 
> org.apache.oozie.action.hadoop.JavaActionExecutor.getRunningJob(JavaActionExecutor.java:1420)
> at 
> org.apache.oozie.action.hadoop.JavaActionExecutor.kill(JavaActionExecutor.java:1623)
> ... 10 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2027) Disable re-runs using the workflow directly if it has a parent

2014-12-26 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2027:
---
Attachment: OOZIE-2027-v1.patch

> Disable re-runs using the workflow directly if it has a parent
> --
>
> Key: OOZIE-2027
> URL: https://issues.apache.org/jira/browse/OOZIE-2027
> Project: Oozie
>  Issue Type: Sub-task
>  Components: workflow
>Affects Versions: trunk
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2027-v0.patch, OOZIE-2027-v1.patch
>
>
> Disable re-runs using the workflow directly if it has a parent. This applies 
> to both cases where parent is coord action/another workflow. This check 
> should be controlled using oozie-site config and should be disabled by 
> default for backward compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2014-12-26 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: OOZIE-2092-v0.patch

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2027) Disable re-runs using the workflow directly if it has a parent

2014-12-26 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2027:
---
Attachment: OOZIE-2027-v2.patch

> Disable re-runs using the workflow directly if it has a parent
> --
>
> Key: OOZIE-2027
> URL: https://issues.apache.org/jira/browse/OOZIE-2027
> Project: Oozie
>  Issue Type: Sub-task
>  Components: workflow
>Affects Versions: trunk
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2027-v0.patch, OOZIE-2027-v1.patch, 
> OOZIE-2027-v2.patch
>
>
> Disable re-runs using the workflow directly if it has a parent. This applies 
> to both cases where parent is coord action/another workflow. This check 
> should be controlled using oozie-site config and should be disabled by 
> default for backward compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2027) Disable re-runs using the workflow directly if it has a parent

2014-12-26 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2027:
---
Attachment: OOZIE-2027-v3.patch

> Disable re-runs using the workflow directly if it has a parent
> --
>
> Key: OOZIE-2027
> URL: https://issues.apache.org/jira/browse/OOZIE-2027
> Project: Oozie
>  Issue Type: Sub-task
>  Components: workflow
>Affects Versions: trunk
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2027-v0.patch, OOZIE-2027-v1.patch, 
> OOZIE-2027-v2.patch, OOZIE-2027-v3.patch
>
>
> Disable re-runs using the workflow directly if it has a parent. This applies 
> to both cases where parent is coord action/another workflow. This check 
> should be controlled using oozie-site config and should be disabled by 
> default for backward compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2027) Disable re-runs using the workflow directly if it has a parent

2014-12-28 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2027:
---
Attachment: OOZIE-2027-v4.patch

Removed one javac warning , Other two are coming from test cases for 
Service.get.getConf.setBoolean(). 

> Disable re-runs using the workflow directly if it has a parent
> --
>
> Key: OOZIE-2027
> URL: https://issues.apache.org/jira/browse/OOZIE-2027
> Project: Oozie
>  Issue Type: Sub-task
>  Components: workflow
>Affects Versions: trunk
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2027-v0.patch, OOZIE-2027-v1.patch, 
> OOZIE-2027-v2.patch, OOZIE-2027-v3.patch, OOZIE-2027-v4.patch
>
>
> Disable re-runs using the workflow directly if it has a parent. This applies 
> to both cases where parent is coord action/another workflow. This check 
> should be controlled using oozie-site config and should be disabled by 
> default for backward compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1889) Convert NamedNativeQueries to JPQL

2014-12-29 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1889:


+1

> Convert NamedNativeQueries to JPQL
> --
>
> Key: OOZIE-1889
> URL: https://issues.apache.org/jira/browse/OOZIE-1889
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: David Villegas
>Assignee: David Villegas
> Fix For: trunk
>
> Attachments: OOZIE-1889.patch, OOZIE-1889.patch
>
>
> Currently, there is only one JPA NamedNativeQuery 
> (GET_READY_ACTIONS_GROUP_BY_JOBID). By converting it to a regular NamedQuery 
> in JPQL, it can take advantage of JPA capabilities, such as configuring the 
> DB schema as a property (Required for issues such as OOZIE-814 and OOZIE-80)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1889) Convert NamedNativeQueries to JPQL

2014-12-29 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1889:


+1

> Convert NamedNativeQueries to JPQL
> --
>
> Key: OOZIE-1889
> URL: https://issues.apache.org/jira/browse/OOZIE-1889
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: David Villegas
>Assignee: David Villegas
> Fix For: trunk
>
> Attachments: OOZIE-1889.patch, OOZIE-1889.patch
>
>
> Currently, there is only one JPA NamedNativeQuery 
> (GET_READY_ACTIONS_GROUP_BY_JOBID). By converting it to a regular NamedQuery 
> in JPQL, it can take advantage of JPA capabilities, such as configuring the 
> DB schema as a property (Required for issues such as OOZIE-814 and OOZIE-80)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2015-01-01 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: OOZIE-2092-v1.patch

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch, OOZIE-2092-v1.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2015-01-01 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: OOZIE-2092-v2.patch

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch, OOZIE-2092-v1.patch, 
> OOZIE-2092-v2.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2015-01-02 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: OOZIE-2092-v3.patch

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch, OOZIE-2092-v1.patch, 
> OOZIE-2092-v2.patch, OOZIE-2092-v3.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2015-01-02 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: OOZIE-2092-v4.patch

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch, OOZIE-2092-v1.patch, 
> OOZIE-2092-v2.patch, OOZIE-2092-v3.patch, OOZIE-2092-v4.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2015-01-02 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: (was: OOZIE-2092-v4.patch)

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch, OOZIE-2092-v1.patch, 
> OOZIE-2092-v2.patch, OOZIE-2092-v3.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2015-01-02 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: OOZIE-2092-v4.patch

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch, OOZIE-2092-v1.patch, 
> OOZIE-2092-v2.patch, OOZIE-2092-v3.patch, OOZIE-2092-v4.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2015-01-04 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: OOZIE-2092-v5.patch

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch, OOZIE-2092-v1.patch, 
> OOZIE-2092-v2.patch, OOZIE-2092-v3.patch, OOZIE-2092-v4.patch, 
> OOZIE-2092-v5.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2092) Provide option to supply config to workflow during rerun of coordinator

2015-01-05 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2092:
---
Attachment: OOZIE-2092-v6.patch

> Provide option to supply config to workflow during rerun of coordinator 
> 
>
> Key: OOZIE-2092
> URL: https://issues.apache.org/jira/browse/OOZIE-2092
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2092-v0.patch, OOZIE-2092-v1.patch, 
> OOZIE-2092-v2.patch, OOZIE-2092-v3.patch, OOZIE-2092-v4.patch, 
> OOZIE-2092-v5.patch, OOZIE-2092-v6.patch
>
>
> After disable reruns using workflow when parent exist. After enabling this 
> flag there should be some way to supply config to workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (OOZIE-1536) Coordinator action reruns start a new workflow

2015-01-05 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma resolved OOZIE-1536.

Resolution: Fixed

> Coordinator action reruns start a new workflow
> --
>
> Key: OOZIE-1536
> URL: https://issues.apache.org/jira/browse/OOZIE-1536
> Project: Oozie
>  Issue Type: Improvement
>Reporter: Srikanth Sundarrajan
>Assignee: Jaydeep Vishwakarma
>
> Coordinator action reruns start a new workflow and if existing workflow for 
> the action is in running state, the same is not checked. Coord rerun can 
> possibly do a workflow re-run to prevent this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1536) Coordinator action reruns start a new workflow

2015-01-05 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1536:


All subtasks have been resolved. I am closing this jira.

> Coordinator action reruns start a new workflow
> --
>
> Key: OOZIE-1536
> URL: https://issues.apache.org/jira/browse/OOZIE-1536
> Project: Oozie
>  Issue Type: Improvement
>Reporter: Srikanth Sundarrajan
>Assignee: Jaydeep Vishwakarma
>
> Coordinator action reruns start a new workflow and if existing workflow for 
> the action is in running state, the same is not checked. Coord rerun can 
> possibly do a workflow re-run to prevent this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-13 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma reassigned OOZIE-1730:
--

Assignee: Jaydeep Vishwakarma

> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-13 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-1730:
---
Attachment: OOZIE-1730.patch

> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-1730.patch
>
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1729) Add support to Hadoop-2 for AM restarts of the launcher job

2015-01-13 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1729:


[~rkanter], Is it ok for you if i provide patch for this, if you are not 
working on it.

> Add support to Hadoop-2 for AM restarts of the launcher job
> ---
>
> Key: OOZIE-1729
> URL: https://issues.apache.org/jira/browse/OOZIE-1729
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Fix For: trunk
>
>
> Once we update our Hadoop-2 to Hadoop 2.4.0, we can add support for AM 
> restarts of the launcher job (OOZIE-1722) for Hadoop-2 instead of just 
> Hadoop-3.  
> This should be fairly trivial: just need to copy
> {{./hadooplibs/hadoop-utils-3/src/main/java/org/apache/oozie/action/hadoop/LauncherMainHadoopUtils.java}}
> in place of
> {{./hadooplibs/hadoop-utils-2/src/main/java/org/apache/oozie/action/hadoop/LauncherMainHadoopUtils.java}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-13 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-1730:
---
Attachment: OOZIE-1730-v1.patch

changing version to 2.6.0.

> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-1730-v1.patch, OOZIE-1730.patch
>
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-17 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1730:


[~rkanter] and [~shwethags], What is the final call? 

> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-1730-v1.patch, OOZIE-1730.patch
>
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (OOZIE-1299) Rerunning the main workflow to rerun sub-workflow and not create new one

2015-01-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma resolved OOZIE-1299.

Resolution: Fixed

This issue has been resolved.

> Rerunning the main workflow to rerun sub-workflow and not create new one
> 
>
> Key: OOZIE-1299
> URL: https://issues.apache.org/jira/browse/OOZIE-1299
> Project: Oozie
>  Issue Type: New Feature
>  Components: workflow
>Affects Versions: 3.3.0
>Reporter: PriyaSundararajan
> Fix For: trunk
>
>
> Consider the case that the oozie workflow  calls sub-workflow. If we kill the 
> main workflow and rerun the same does not rerun the same sub-workflow,instead 
> it creates new sub-workflow.
> For example:
> Workflow Id 004-130401101507291-oozie-oozi-W calls the sub-workflow 
> 005-130401101507291-oozie-oozi-W.Sub-workflow fails 
> (005-130401101507291-oozie-oozi-W i.e main workflow 
> (004-130401101507291-oozie-oozi-W) also be killed).If we rerun the main 
> workflow(004-130401101507291-oozie-oozi-W)again, it doesn't rerun the 
> same sub-workflow(005-130401101507291-oozie-oozi-W),instead it call 
> another sub-workflow(006-130401101507291-oozie-oozi-W).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-547) build workflow progress information in Oozie

2015-01-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-547:
---

[~zhujinwei], Nice feature to have in oozie, It would help a lot.
 Are you still working on it?

> build workflow progress information in Oozie
> 
>
> Key: OOZIE-547
> URL: https://issues.apache.org/jira/browse/OOZIE-547
> Project: Oozie
>  Issue Type: New Feature
>Reporter: Hadoop QA
>Assignee: zhu jin wei
> Attachments: oozie-547.patch
>
>
> For a user, knowing progress of her workflow is always desirable. This ticket 
> is to introduce this support to Oozie.
> I know it's a hard problem. For my initial effort, I plan to start with 
> simple workflows that do not contain decision nodes or fork/join nodes, i.e., 
> chain type workflows. I plan to use percentage of finished actions as the 
> overall wf progress estimate.
> Going forward we can improve the estimation by:
> 1) handle general workflows that contain decision, fork/join nodes;
> 2) incorporate the action level progress into wf level progress estimation to 
> make the estimate better. To be more specific:
> In the case of "opaque" actions like pig/hive/jaql where the status can only 
> be 0% or 100% (or failure) we plug that value into the overall DAG status of 
> 0-100%. If a DAG had say 4 opaque actions, the progress would move in 
> discrete steps 0, 25, 50, 75, 100%.  For the m/r actions where the JobTracker
> gives values between 0-100% for an action then the overall progress will be 
> smoother. We can do same thing for pig/hive/jaql actions as well if they 
> expose their own progress info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1222) Improve OOZIE Coordinator Action rerun

2015-01-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1222:


[~szzhu], I think your most of the concerns related to rerun have been taken 
care in following jira. 
https://issues.apache.org/jira/browse/OOZIE-1536
Please add the sub task there if anything additional you want to add.

> Improve OOZIE Coordinator Action rerun
> --
>
> Key: OOZIE-1222
> URL: https://issues.apache.org/jira/browse/OOZIE-1222
> Project: Oozie
>  Issue Type: Improvement
>  Components: coordinator
>Affects Versions: 3.2.0
>Reporter: Shanzhong Zhu
>
> Current rerunning a coordinator action resets its external id (which maps to 
> workflow job) and external status. This means it will run a fresh workflow 
> job which explains why the client method getRerun() was returning '0'.
> Can we enhance the coordinator rerun to be consistent with the workflow rerun?
> * Keep the same workflow ID.
> * Support rerun from beginning or rerun from the failed WF action (Right now 
> rerun a coordinator action always rerunning from beginning).
> * Rerun count (getReRun() ) reflects the number of tries. (Rignt now, it's 
> always returning 0).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-01-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma reassigned OOZIE-2020:
--

Assignee: Jaydeep Vishwakarma

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Assignee: Jaydeep Vishwakarma
>Priority: Minor
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Reopened] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma reopened OOZIE-1730:


> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Fix For: trunk
>
> Attachments: OOZIE-1730-v1.patch, OOZIE-1730.patch
>
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-1730:
---
Attachment: OOZIE-1730-v2.patch

[~rkanter], I missed some file to add, my mistake please add them as well, I 
was getting protobuf miss match error during test cases.  
"java.lang.VerifyError: class 
org.apache.hadoop.hdfs.server.namenode.FsImageProto$FileSummary overrides final 
method getUnknownFields.()Lcom/google/protobuf/UnknownFieldSet;"

> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Fix For: trunk
>
> Attachments: OOZIE-1730-v1.patch, OOZIE-1730-v2.patch, 
> OOZIE-1730.patch
>
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-1730:
---
Attachment: (was: OOZIE-1730-v2.patch)

> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Fix For: trunk
>
> Attachments: OOZIE-1730-v1.patch, OOZIE-1730-v2.patch, 
> OOZIE-1730.patch
>
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-1730:
---
Attachment: OOZIE-1730-v2.patch

> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Fix For: trunk
>
> Attachments: OOZIE-1730-v1.patch, OOZIE-1730-v2.patch, 
> OOZIE-1730.patch
>
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1730) Change hadoop-2 profile to use 2.4.0

2015-01-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1730:


Thank you very much Robert!!

> Change hadoop-2 profile to use 2.4.0
> 
>
> Key: OOZIE-1730
> URL: https://issues.apache.org/jira/browse/OOZIE-1730
> Project: Oozie
>  Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Fix For: trunk
>
> Attachments: OOZIE-1730-v1.patch, OOZIE-1730-v2.patch, 
> OOZIE-1730.patch
>
>
> - Update the hadoop-2 profile to use Hadoop 2.4.0
> - Update the version we use for mini-kdc to be 2.4.0
> - Make sure all the tests pass and that it actually works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-1729) Add support to Hadoop-2 for AM restarts of the launcher job

2015-01-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-1729:
---
Attachment: OOZIE-1729-v0.patch

> Add support to Hadoop-2 for AM restarts of the launcher job
> ---
>
> Key: OOZIE-1729
> URL: https://issues.apache.org/jira/browse/OOZIE-1729
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Fix For: trunk
>
> Attachments: OOZIE-1729-v0.patch
>
>
> Once we update our Hadoop-2 to Hadoop 2.4.0, we can add support for AM 
> restarts of the launcher job (OOZIE-1722) for Hadoop-2 instead of just 
> Hadoop-3.  
> This should be fairly trivial: just need to copy
> {{./hadooplibs/hadoop-utils-3/src/main/java/org/apache/oozie/action/hadoop/LauncherMainHadoopUtils.java}}
> in place of
> {{./hadooplibs/hadoop-utils-2/src/main/java/org/apache/oozie/action/hadoop/LauncherMainHadoopUtils.java}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1729) Add support to Hadoop-2 for AM restarts of the launcher job

2015-01-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1729:


I have verified it locally , testSparkAction is failing even without this 
patch. 

> Add support to Hadoop-2 for AM restarts of the launcher job
> ---
>
> Key: OOZIE-1729
> URL: https://issues.apache.org/jira/browse/OOZIE-1729
> Project: Oozie
>  Issue Type: Sub-task
>Reporter: Robert Kanter
>Assignee: Jaydeep Vishwakarma
> Fix For: trunk
>
> Attachments: OOZIE-1729-v0.patch
>
>
> Once we update our Hadoop-2 to Hadoop 2.4.0, we can add support for AM 
> restarts of the launcher job (OOZIE-1722) for Hadoop-2 instead of just 
> Hadoop-3.  
> This should be fairly trivial: just need to copy
> {{./hadooplibs/hadoop-utils-3/src/main/java/org/apache/oozie/action/hadoop/LauncherMainHadoopUtils.java}}
> in place of
> {{./hadooplibs/hadoop-utils-2/src/main/java/org/apache/oozie/action/hadoop/LauncherMainHadoopUtils.java}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-02-06 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


This is happening with other actions also.  Earlier fix does not propagates 
tags information to child jobs which launch by launcher.

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-02-07 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v0.patch

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-02-07 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


I have done the test in following scenarios:

+Workflow with pig/java action+
- Kill Launcher mapper attempt
- Restart node manager on which app-master is running
- Kill launcher job - Follow up with workflow retry

+Coord job +Direct workflow with pig/java action+
- Kill Launcher mapper attempt
- Restart node manager on which app-master is running
- Kill launcher job - Follow up with workflow retry
- Kill launcher job - Follow up with coord action retry

+Coord job +Subflow workflow with pig/java action+
- Kill Launcher mapper attempt
- Restart node manager on which app-master is running
- Kill launcher job - Follow up with workflow retry
- Kill launcher job - Follow up with coord action retry

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-02-07 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


Some issue is going on with review board unable to upload patch in review 
board. I will add it in review board once it will be fine.

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-02-08 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


TestSparkActionExecutor is failing, It is failing without apply this patch as 
well. 

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-02-11 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v1.patch

[~shwethags] 
1. All ActionExecutor extends JavaActionExecutor so no issue with it.
2. I just went through hadoop-3 profile. I am unable to even compile it, I can 
see various issues with it. I will create the separate jira and fix the profile 
and then i will have only single hadoop-utils. For now I am just doing copy 
paste of it the same code.
3. Using child.mapreduce.job.tags in LauncherMainHadoopUtils.
4. printing application id as well.
5. Passing tag as --hiveconf in Hive2Main

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OOZIE-2138) Haodop-3 profile have compilation error.

2015-02-11 Thread Jaydeep Vishwakarma (JIRA)
Jaydeep Vishwakarma created OOZIE-2138:
--

 Summary: Haodop-3 profile have compilation error.
 Key: OOZIE-2138
 URL: https://issues.apache.org/jira/browse/OOZIE-2138
 Project: Oozie
  Issue Type: Bug
  Components: build
Reporter: Jaydeep Vishwakarma
Assignee: Jaydeep Vishwakarma


Hadoop-3 profile is not getting compiled. I can see some modules like 
hadoop-auth-2 is missing. 
 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2138) Haodop-3 profile have compilation error.

2015-02-11 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2138:
---
Description: 
Hadoop-3 profile is not getting compiled. I can see some modules like 
hadoop-auth-3 is missing. 
 

  was:
Hadoop-3 profile is not getting compiled. I can see some modules like 
hadoop-auth-2 is missing. 
 


> Haodop-3 profile have compilation error.
> 
>
> Key: OOZIE-2138
> URL: https://issues.apache.org/jira/browse/OOZIE-2138
> Project: Oozie
>  Issue Type: Bug
>  Components: build
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
>
> Hadoop-3 profile is not getting compiled. I can see some modules like 
> hadoop-auth-3 is missing. 
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-02-11 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


Jira for hadoop-3 profile.
https://issues.apache.org/jira/browse/OOZIE-2138 

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2042) Max substitution for config variables should be configurable

2015-02-12 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2042:


[~rkanter], Just curious what is the intention behind to fix the limit for max 
substitution, Can be just not leave this on run time instead of keeping it fix 
length or config driven?

> Max substitution for config variables should be configurable
> 
>
> Key: OOZIE-2042
> URL: https://issues.apache.org/jira/browse/OOZIE-2042
> Project: Oozie
>  Issue Type: Improvement
>  Components: core
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Azrael
> Fix For: trunk
>
> Attachments: OOZIE-2042.1.patch
>
>
> The max number of substitutions in a config variable is currently hardcoded 
> at 20 in XConfiguration.  We should make this configurable.
> https://github.com/apache/oozie/blob/master/core/src/main/java/org/apache/oozie/util/XConfiguration.java#L146



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2044) ssh action succeed with a not exists command which should be fail.

2015-02-12 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2044:


+1

> ssh action succeed with a not exists command which should be fail.
> --
>
> Key: OOZIE-2044
> URL: https://issues.apache.org/jira/browse/OOZIE-2044
> Project: Oozie
>  Issue Type: Bug
>  Components: action, core
>Affects Versions: trunk
>Reporter: PENG Yongyi
> Attachments: OOZIE-2044.patch
>
>
> it's should fail but succeed as follow action:
> 
>   localhost
>   /bin/not-exists-command
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-02-12 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


I am still unable to upload the code in review board, Am I the only person who 
facing this problem? Anyone knows who manages review board?

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-02-12 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


[~rkanter] 
My replies are inline

# Why do we get rid of {code}gar.setStartRange(startTime, 
System.currentTimeMillis());{code}? IIRC, I put this in to help lower the cost 
on YARN's side of looking up apps by tags. We don't have to look any earlier 
than startTime.
#* As my understanding yarn do not manage any index, So doing the filter based 
on time is just adding another level of complexcity. Correct me if I am wrong.
# I'm not sure we should add support for this to the Java action. While you can 
run MR jobs from it, and many users do, we've typically avoided adding 
MR-specific features to it to encourage users to use the MR action. The Java 
action's primary purpose is to run Java programs.
#* I feel we cannot go with this assumption. I am observed many user including 
me using java action for running map-reduce job. Find easy to have controls. 
# I'm not sure if this is a problem, but if the user upgrades to a version of 
Oozie with this patch, any actions running during the upgrade won't be able to 
properly use the tags, right? Even if that's a problem, it's not likely to 
occur.
#* Even now also {code}LauncherMapper{code} does not pass tag to child jobs, It 
is basically a fix which will resolve the issue for all the jobs which will be 
launch after applying this patch.
# In {code}LauncherMapper{code}, don't replace the {code}java.io{code} import 
with {code}import java.io.;{code} we don't typically use {} for imports
#* I have checked my default settings of idea, It is brining this imports. I 
will fix it.
#I'm not sure I understand how the {code}propagation-conf.xml{code} is used; 
aren't all of the necessary configs appropriately set in the launcher and 
action confs already?
#* I am using {code}propagation-conf.xml{code} for java action and for others 
{code}mapreduce.job.tags{code} will be just duplicate value. There is no such 
contract available in JavaMain to pass the conf value.


> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-02-12 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


[~rkanter]
Ops, I have screwed up with the format, Please let me know if you have any 
doubt. 

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1638) Action retry does not use default retry max count.

2015-02-19 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1638:


change the message "Automatic retry max count for workflow action is 3 in 
default."  to "Automatic retry max count for workflow action is 0 in default."

> Action retry does not use default retry max count.
> --
>
> Key: OOZIE-1638
> URL: https://issues.apache.org/jira/browse/OOZIE-1638
> Project: Oozie
>  Issue Type: Bug
>  Components: action
>Affects Versions: 4.0.0
>Reporter: Azrael
>Assignee: Azrael
>Priority: Minor
> Attachments: OOZIE-1638.2.patch, OOZIE-1638.3.patch, 
> OOZIE-1638.4.patch, OOZIE-1638.5.patch, OOZIE-1638.6.patch, OOZIE-1638.patch
>
>
> the oozie-default
> {code:xml}
> 
> oozie.service.LiteWorkflowStoreService.user.retry.max
> 3
> 
> Automatic retry max count for workflow action is 3 in default.
> 
> 
> {code}
> but the action failed with error, is not retried. 
> It should retry $\{user.retry.max\} times.
> If the patch applied, some other tests in TestActionError failed because the 
> action is not terminated for retrying.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1918) ActionXCommand refactoring for code reuse

2015-02-19 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1918:


These classes have so many changes from when you uploaded the patch. Can you 
please rebase your code and upload the patch again , I would like to review the 
patch.

> ActionXCommand refactoring for code reuse
> -
>
> Key: OOZIE-1918
> URL: https://issues.apache.org/jira/browse/OOZIE-1918
> Project: Oozie
>  Issue Type: Improvement
>  Components: action
>Affects Versions: trunk
>Reporter: Azrael
>Assignee: Azrael
>Priority: Trivial
> Attachments: OOZIE-1918.1.patch, OOZIE-1918.2.patch
>
>
> Subclasses of ActionXCommand have some duplicated code. Refactoring make it 
> more neat.
> This patch contain:
> * Renaming CompletedActionXCommand to ActionCompletedXCommand and extending 
> ActionXCommand
> * Moving some variables and methods to ActionXCommand and making it protected
> * More meaningful log message : actionId is duplicated so removed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-02-22 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v2.patch

Code formatting issue. 
Move launcher tag from {{JavaActionExecutor.java}} which set the actionid as 
tag when there is no parent and added it to {{ActionStartXCommand.java}}.

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1976) Specifying coordinator input datasets in more logical ways

2015-02-23 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1976:


[~chitnis] , This jira will a big milestone for oozie. I can see the high value 
to add it. if we break this in subtask it would be more easy to work on it and 
also reviewer will not have any difficulty to review it.  Can you also upload 
the jira on review board.

> Specifying coordinator input datasets in more logical ways
> --
>
> Key: OOZIE-1976
> URL: https://issues.apache.org/jira/browse/OOZIE-1976
> Project: Oozie
>  Issue Type: New Feature
>  Components: coordinator
>Affects Versions: trunk
>Reporter: Mona Chitnis
>Assignee: Mona Chitnis
> Fix For: trunk
>
> Attachments: OOZIE-1976-WIP.patch, OOZIE-1976-rough-design-2.pdf, 
> OOZIE-1976-rough-design.pdf
>
>
> All dataset instances specified as input to coordinator, currently work on 
> AND logic i.e. ALL of them should be available for workflow to start. We 
> should enhance this to include more logical ways of specifying availability 
> criteria e.g.
>  * OR between instances
>  * minimum N out of K instances
>  * delta datasets (process data incrementally)
> Use-cases for this:
>  * Different datasets are BCP, and workflow can run with either, whichever 
> arrives earlier.
>  * Data is not guaranteed, and while $coord:latest allows skipping to 
> available ones, workflow will never trigger unless mentioned number of 
> instances are found.
>  * Workflow is like a ‘refining’ algorithm which should run after minimum 
> required datasets are ready, and should only process the delta for efficiency.
> This JIRA is to discuss the design and then the review the implementation for 
> some or all of the above features.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-1976) Specifying coordinator input datasets in more logical ways

2015-02-24 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-1976:


[~chitnis], Are you working on this? If not, I can take it up.

> Specifying coordinator input datasets in more logical ways
> --
>
> Key: OOZIE-1976
> URL: https://issues.apache.org/jira/browse/OOZIE-1976
> Project: Oozie
>  Issue Type: New Feature
>  Components: coordinator
>Affects Versions: trunk
>Reporter: Mona Chitnis
>Assignee: Mona Chitnis
> Fix For: trunk
>
> Attachments: OOZIE-1976-WIP.patch, OOZIE-1976-rough-design-2.pdf, 
> OOZIE-1976-rough-design.pdf
>
>
> All dataset instances specified as input to coordinator, currently work on 
> AND logic i.e. ALL of them should be available for workflow to start. We 
> should enhance this to include more logical ways of specifying availability 
> criteria e.g.
>  * OR between instances
>  * minimum N out of K instances
>  * delta datasets (process data incrementally)
> Use-cases for this:
>  * Different datasets are BCP, and workflow can run with either, whichever 
> arrives earlier.
>  * Data is not guaranteed, and while $coord:latest allows skipping to 
> available ones, workflow will never trigger unless mentioned number of 
> instances are found.
>  * Workflow is like a ‘refining’ algorithm which should run after minimum 
> required datasets are ready, and should only process the delta for efficiency.
> This JIRA is to discuss the design and then the review the implementation for 
> some or all of the above features.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-03-02 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


1. Added back the launch time in filter.
3. Yes this patch will fix the issue. I meant without this patch it will not 
work.
For 2 and 5 :  "they have to implement some code"  propagation.xml is the way 
for the launcher to share details in case they need to take advantage of it, 
since there are no other simple ways or established contract to share info in a 
backward compatible way.  
6. Yes, when any coord_action/workflow/launcher are running, oozie will not 
allow to rerun. The issues comes when the job launched by launcher is in 
running state and coord_action/workflow/launcher is in killed state, In this 
case, before rerunning the coord_action/workflow/launcher none of the previous 
launched job is running on cluster. Check my second comment in the same jira 
that explain in what cases this condition can occur. 


> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-02 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v3.patch

Added time filter in for launcher tag.

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-03-03 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma reassigned OOZIE-2020:
--

Assignee: Jaydeep Vishwakarma

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Assignee: Jaydeep Vishwakarma
>Priority: Minor
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-03-03 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2020:
---
Assignee: (was: Jaydeep Vishwakarma)

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Priority: Minor
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-03-11 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2020:
---
Assignee: (was: Jaydeep Vishwakarma)

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Priority: Minor
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-03-11 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma reassigned OOZIE-2020:
--

Assignee: Jaydeep Vishwakarma

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Assignee: Jaydeep Vishwakarma
>Priority: Minor
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-12 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v4.patch

[~rkanter], In one of the use case we are facing some issue during rerun, That 
action belongs to mapreduce action. Here is the following set of message I am 
getting. 
{quote}
Found Map-Reduce job [application_1425984146247_68771] already running
JobId file is mising: writing now... DoneExiting launcher
{quote}

It is stopping to run the rerun the child job from launcher. For fixing this 
for Map reduce action I have removed method 
{{LauncherMainHadoopUtils.getYarnJobForMapReduceAction}} and using 
{{LauncherMainHadoopUtils.killChildYarnJobs}}. 
Please let me know if you have any concern.

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-16 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v5.patch

[~rkanter], Taking care of item 2,3,4.  I have rechecked, all Mr configuration 
properties which introduced by this patch are starting with "oozie."

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-03-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2020:
---
Assignee: (was: Jaydeep Vishwakarma)

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Priority: Minor
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-03-18 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma reassigned OOZIE-2020:
--

Assignee: Jaydeep Vishwakarma

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Assignee: Jaydeep Vishwakarma
>Priority: Minor
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v6.patch

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch, OOZIE-2129-v6.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: (was: OOZIE-2129-v6.patch)

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v6.patch

# Removed :
{code}
+} else {
+launcherTag = action.getId();
+}
{code}

# {{LauncherMain}} is in sharelib module. Is that fine to add dependency to use 
the variable only? I have created local constant variable for now.
# Keeping value as {{"oozie.child.mapreduce.job.tags"}} , It will also indicate 
that this config is for child job launched by launcher.
# Passing {{MAPRED_JOB_TAGS}} so that other tags which added by user will pass 
to hive conf.
# Removed {writeJobIdFile(idFile, jobId)} and other related code.
# 
{code}
+arguments.add("mapreduce.job.tags=" + 
actionConf.get("mapreduce.job.tags"));
{code}
I am calling method {{setYarntag}} during initializing configuration. So it is 
fine. By this we will be able to pass user tags as well.

I have done one more change in {{LauncherMainHadoopUtils}}.
{code}
String tag = actionConf.get(CHILD_MAPREDUCE_JOB_TAGS);
{code}
Earlier it was {{String tag = actionConf.get(MAPREDUCE_JOB_TAGS);}}, It will 
give only the tag which created by oozie.


> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch, OOZIE-2129-v6.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: (was: OOZIE-2129-v6.patch)

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-21 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v6.patch

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch, OOZIE-2129-v6.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-23 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v7.patch

Keeping following code to backward compatibility with test cases.
{code}
+} else {
+launcherTag = action.getId();
+}
{code}

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch, OOZIE-2129-v6.patch, OOZIE-2129-v7.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-23 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: (was: OOZIE-2129-v7.patch)

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch, OOZIE-2129-v6.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-23 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v7.patch

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch, OOZIE-2129-v6.patch, OOZIE-2129-v7.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2129) Duplicate child jobs per instance

2015-03-23 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2129:
---
Attachment: OOZIE-2129-v8.patch

Keeping {{writeJobIdFile}} method in {{MapReduceMain}} to write the job id. 
It has been using in {{LauncherMapper}} for following code 
{code}
// id swap
String newIdProp = System.getProperty(ACTION_PREFIX + 
ACTION_DATA_NEW_ID);
if (newIdProp != null) {
File newId = new File(newIdProp);
if (newId.exists()) {
actionData.put(ACTION_DATA_NEW_ID, 
getLocalFileContentStr(newId, "", -1));
}
}
{code}
Test cases are for same reason.

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch, OOZIE-2129-v6.patch, OOZIE-2129-v7.patch, 
> OOZIE-2129-v8.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2129) Duplicate child jobs per instance

2015-03-24 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2129:


These failures are not related to patch. I have checked in my local, All those 
test cases are working fine.

> Duplicate child jobs per instance
> -
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch, 
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch, 
> OOZIE-2129-v5.patch, OOZIE-2129-v6.patch, OOZIE-2129-v7.patch, 
> OOZIE-2129-v8.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this 
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So, 
> it doesn't ensure old child job is killed at launcher start



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-04-03 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2020:


Hi, Can any committer add  [~nperiwal] as contributor,He is working on this 
jira.  I am unable to assign him this jira as he is not in the contributor list.

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Assignee: Jaydeep Vishwakarma
>Priority: Minor
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2020) Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers

2015-04-05 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2020:


[~nperiwal] Remove the prefix from the patch and submit the patch again.

> Rerun all Failed/killed/timedout coordinator actions rather than specifying 
> action numbers
> --
>
> Key: OOZIE-2020
> URL: https://issues.apache.org/jira/browse/OOZIE-2020
> Project: Oozie
>  Issue Type: New Feature
>  Components: action
>Reporter: Sreedish P S
>Assignee: Narayan Periwal
>Priority: Minor
> Attachments: OOZIE-2020-v3.patch
>
>
> Currently rerun of coordinator actions are made through coordinator id and 
> action numbers, this feature request is for rerunning all coordinator actions 
> by mentioning a particular state
> for example :
> oozie job -rerun coord-id -state killed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OOZIE-2195) Expose Pig read/write bytes details as counters in Launcher

2015-04-06 Thread Jaydeep Vishwakarma (JIRA)
Jaydeep Vishwakarma created OOZIE-2195:
--

 Summary: Expose Pig read/write bytes details as counters in 
Launcher
 Key: OOZIE-2195
 URL: https://issues.apache.org/jira/browse/OOZIE-2195
 Project: Oozie
  Issue Type: New Feature
Reporter: Jaydeep Vishwakarma


Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
metrics are emitted in logs only. It would be really helpful if we expose those 
information in Launcher as counters. 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2195) Expose Pig read/write bytes details as counters in Launcher

2015-04-06 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2195:
---
Description: 
Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
metrics are emitted in logs only. It would be really helpful if we expose those 
information in Launcher as counters.  This should not be the default behaviour. 
User can enable this by job level or global 
configuration.

  was:
Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
metrics are emitted in logs only. It would be really helpful if we expose those 
information in Launcher as counters.  This should not be the default behaviour. 
User can enable this by config on job level or global 



> Expose Pig read/write bytes details as counters in Launcher
> ---
>
> Key: OOZIE-2195
> URL: https://issues.apache.org/jira/browse/OOZIE-2195
> Project: Oozie
>  Issue Type: New Feature
>Reporter: Jaydeep Vishwakarma
>
> Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
> metrics are emitted in logs only. It would be really helpful if we expose 
> those information in Launcher as counters.  This should not be the default 
> behaviour. User can enable this by job level or global 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OOZIE-2195) Expose Pig read/write bytes details as counters in Launcher

2015-04-06 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma updated OOZIE-2195:
---
Description: 
Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
metrics are emitted in logs only. It would be really helpful if we expose those 
information in Launcher as counters.  This should not be the default behaviour. 
User can enable this by config on job level or global 


  was:
Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
metrics are emitted in logs only. It would be really helpful if we expose those 
information in Launcher as counters. 



> Expose Pig read/write bytes details as counters in Launcher
> ---
>
> Key: OOZIE-2195
> URL: https://issues.apache.org/jira/browse/OOZIE-2195
> Project: Oozie
>  Issue Type: New Feature
>Reporter: Jaydeep Vishwakarma
>
> Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
> metrics are emitted in logs only. It would be really helpful if we expose 
> those information in Launcher as counters.  This should not be the default 
> behaviour. User can enable this by config on job level or global 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2195) Expose Pig read/write bytes details as counters in Launcher

2015-04-06 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2195:


We can use Input and output variables as counter names and can keep bytes as 
counter value.  In Launcher we can group them as pig counters. Any suggestion 
or issue with the approach or with feature please raise it out.

> Expose Pig read/write bytes details as counters in Launcher
> ---
>
> Key: OOZIE-2195
> URL: https://issues.apache.org/jira/browse/OOZIE-2195
> Project: Oozie
>  Issue Type: New Feature
>Reporter: Jaydeep Vishwakarma
>
> Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
> metrics are emitted in logs only. It would be really helpful if we expose 
> those information in Launcher as counters.  This should not be the default 
> behaviour. User can enable this by job level or global 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OOZIE-2196) Create Local Client for Bundle

2015-04-06 Thread Jaydeep Vishwakarma (JIRA)
Jaydeep Vishwakarma created OOZIE-2196:
--

 Summary: Create Local Client for Bundle
 Key: OOZIE-2196
 URL: https://issues.apache.org/jira/browse/OOZIE-2196
 Project: Oozie
  Issue Type: New Feature
  Components: bundle
Reporter: Jaydeep Vishwakarma
Assignee: Narayan Periwal


Client API to submit and manage Oozie bundle jobs against an Oozie instance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OOZIE-2195) Expose Pig read/write bytes details as counters in Launcher

2015-04-07 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma reassigned OOZIE-2195:
--

Assignee: Jaydeep Vishwakarma

> Expose Pig read/write bytes details as counters in Launcher
> ---
>
> Key: OOZIE-2195
> URL: https://issues.apache.org/jira/browse/OOZIE-2195
> Project: Oozie
>  Issue Type: New Feature
>Reporter: Jaydeep Vishwakarma
>Assignee: Jaydeep Vishwakarma
>
> Pig action spawns multiple mr jobs and all the aggregated read/write bytes 
> metrics are emitted in logs only. It would be really helpful if we expose 
> those information in Launcher as counters.  This should not be the default 
> behaviour. User can enable this by job level or global 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OOZIE-2134) Remove references to Services.get().getConf() in code

2015-04-09 Thread Jaydeep Vishwakarma (JIRA)

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

Jaydeep Vishwakarma commented on OOZIE-2134:


Observing values are missing in many places. Any conf value missing in config 
will end up to setting zero for them.

> Remove references to Services.get().getConf() in code
> -
>
> Key: OOZIE-2134
> URL: https://issues.apache.org/jira/browse/OOZIE-2134
> Project: Oozie
>  Issue Type: Task
>Reporter: Rohini Palaniswamy
>Assignee: Azrael
>  Labels: newbie
> Attachments: OOZIE-2134.1.patch, OOZIE-2134.2.patch
>
>
>Make getConf() package protected and switch all references of 
> Services.get().getConf() to ConfigurationService.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


  1   2   3   4   5   >