[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753959#comment-13753959
]
Mona Chitnis commented on OOZIE-1448:
-
{quote}
Ideally, this piece should be removed and the RecoveryService should have way
to recover this command. Also, due to no recovery of this command, its always
being called directly instead of being queued.
{quote}
I am looking at removing this piece as part of DB calls optimization patch
OOZIE-1503
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch, OOZIE-1448.patch,
> OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735125#comment-13735125
]
Virag Kothari commented on OOZIE-1448:
--
[~tucu00], [~rkanter], OOZIE-1424 doesn't have to do anything with this. ( I
searched for 'new CoordActionUpdateXCommand' but no entry). I believe this has
been in Oozie since a long time.
I think we have this hacky retry logic because if there is some exception in
retrieving the bean, we dont want to immediately fail the command. We retry few
times because if the command fails, there is no way of retrieving it again.
Ideally, this piece should be removed and the RecoveryService should have way
to recover this command. Also, due to no recovery of this command, its always
being called directly instead of being queued.
Robert, For the coord action being null it seems that was only required before
your patch. Now it can be removed as you take care in updateParentIfNecessary.
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch, OOZIE-1448.patch,
> OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735007#comment-13735007
]
Alejandro Abdelnur commented on OOZIE-1448:
---
+1 LGTM. Still there is some weirdness here, why do we need to retry updating
the parent
{code}
new CoordActionUpdateXCommand(wfjob, maxRetries).call();
{code}
[~virag], it seems you did this as part of OOZIE-1424, can you please explain
the reason of this retry?
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch, OOZIE-1448.patch,
> OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734363#comment-13734363
]
Hadoop QA commented on OOZIE-1448:
--
Testing JIRA OOZIE-1448
Cleaning local svn workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:green}+1{color} the patch does adds/modifies 1 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:green}+1 TESTS{color}
.Tests run: 1271
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:green}*+1 Overall result, good!, no -1s*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/700/
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch, OOZIE-1448.patch,
> OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733937#comment-13733937
]
Alejandro Abdelnur commented on OOZIE-1448:
---
wouldn't make sense to have an {{updateParentIfNecessary(wfJob)}} method and
used it in all places instead duplicating the following code multiple times?
{code}
+// update coordinator action if the wf was actually
started by a coord
+if (wfJob.getParentId() != null &&
wfJob.getParentId().contains("-C@")) {
+new CoordActionUpdateXCommand(wfJob, 3).call();
+}
{code}
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch, OOZIE-1448.patch,
> OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733786#comment-13733786
]
Robert Kanter commented on OOZIE-1448:
--
Test failure is unrelated (SLA).
New javac warning seems to be a false positive.
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch, OOZIE-1448.patch,
> OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733781#comment-13733781
]
Hadoop QA commented on OOZIE-1448:
--
Testing JIRA OOZIE-1448
Cleaning local svn workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:green}+1{color} the patch does adds/modifies 1 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:red}-1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:red}-1{color} the patch seems to introduce 1 new javac warning(s)
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
.Tests run: 1270
.Tests failed: 0
.Tests errors: 1
.The patch failed the following testcases:
.
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/698/
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch, OOZIE-1448.patch,
> OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733150#comment-13733150
]
Hadoop QA commented on OOZIE-1448:
--
Testing JIRA OOZIE-1448
Cleaning local svn workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:green}+1{color} the patch does adds/modifies 1 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:red}-1 COMPILE{color}
.{color:red}-1{color} HEAD does not compile
.{color:red}-1{color} patch does not compile
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color} - patch does not compile, cannot run testcases
{color:red}-1 DISTRO{color}
.{color:red}-1{color} distro tarball fails with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/697/
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732704#comment-13732704
]
Alejandro Abdelnur commented on OOZIE-1448:
---
+1 after rerunning tests once OOZIE-1449 is in.
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706522#comment-13706522
]
Robert Kanter commented on OOZIE-1448:
--
When investigating the failures, I realized that I introduced a bug with the
parent id of workflows when redoing the purge logic for OOZIE-1118. I've
created OOZIE-1449 to fix it.
I think we should wait until after OOZIE-1449 is in and re-run the tests to be
sure.
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706386#comment-13706386
]
Virag Kothari commented on OOZIE-1448:
--
+1, check if any failed test cases are related to the patch
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706361#comment-13706361
]
Hadoop QA commented on OOZIE-1448:
--
Testing JIRA OOZIE-1448
Cleaning local svn workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:red}-1{color} the patch does not add/modify any testcase
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
.Tests run: 1256
.Tests failed: 6
.Tests errors: 2
.The patch failed the following testcases:
.
testBundleStatusTransitServiceKilled(org.apache.oozie.service.TestStatusTransitService)
.
testBundleStatusTransitServiceSuspended(org.apache.oozie.service.TestStatusTransitService)
.
testCoordStatusTransitServiceKilledByUser1(org.apache.oozie.service.TestStatusTransitService)
.
testBundleStatusTransitServiceRunningWithError(org.apache.oozie.service.TestStatusTransitService)
.
testStartNonTransientWithCoordActionUpdate(org.apache.oozie.command.wf.TestActionErrors)
.
testEndNonTransientWithCoordActionUpdate(org.apache.oozie.command.wf.TestActionErrors)
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/656/
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch, OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706239#comment-13706239
]
Hadoop QA commented on OOZIE-1448:
--
Testing JIRA OOZIE-1448
Cleaning local svn workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:red}-1{color} the patch does not add/modify any testcase
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
.Tests run: 1256
.Tests failed: 1
.Tests errors: 2
.The patch failed the following testcases:
.
testEvictionOnTimeToIdle(org.apache.oozie.service.TestPartitionDependencyManagerEhcache)
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/655/
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706209#comment-13706209
]
Robert Kanter commented on OOZIE-1448:
--
Good catch, I didn't realize that other commands were doing the same thing;
I'll create a new patch shortly.
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1448) A CoordActionUpdateXCommand gets queued for all workflows even if they were not launched by a coordinator
[
https://issues.apache.org/jira/browse/OOZIE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706207#comment-13706207
]
Virag Kothari commented on OOZIE-1448:
--
Along with SignalX, we can do this at other places where
CoordActionUpdateXCommand is called like SuspendX, ResumeX, KillX etc.
Also, I dont know why CoordActionUpdateXCommand is always called directly
everywhere in Oozie and not queued
> A CoordActionUpdateXCommand gets queued for all workflows even if they were
> not launched by a coordinator
> -
>
> Key: OOZIE-1448
> URL: https://issues.apache.org/jira/browse/OOZIE-1448
> Project: Oozie
> Issue Type: Bug
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1448.patch
>
>
> Once a workflow (that wasn't started by a coordinator) ends, there's almost
> always a warning/error logged that looks like this:
> {noformat}
> 2013-07-09 16:16:54,711 WARN CoordActionUpdateXCommand:542 - USER[rkanter]
> GROUP[-] TOKEN[] APP[pig-wf] JOB[000-130709161625948-oozie-rkan-W]
> ACTION[-] E1100: Command precondition does not hold before execution, [,
> coord action is null], Error Code: E1100
> {noformat}
> The error is harmless, but it tends to confuse users who think that something
> went wrong. It also means that we have an extra unnecessary command in the
> queue for every workflow that wasn't started by a coordinator.
> In SignalXCommand, there is a line like this:
> {code:java}
> new CoordActionUpdateXCommand(wfJob).call();//Note: Called even if wf is
> not necessarily instantiated by coordinator
> {code}
> The comment is part of the original code, and makes me think that this was
> done on purpose or perhaps when there wasn't a good way to check if a
> workflow was started by a coordinator?
> I think we can fix this by simply checking if the parent of {{wfJob}} is a
> coordinator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
