Bug 809615 - Operation run through "Execute Prompt Command" incorrectly reported as failure in server UI
Operation run through "Execute Prompt Command" incorrectly reported as failur...
Status: CLOSED WONTFIX
Product: JBoss Operations Network
Classification: JBoss
Component: Agent (Show other bugs)
JON 3.0.0
Unspecified Unspecified
unspecified Severity low
: ---
: JON 3.3.0
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks: 810911
  Show dependency treegraph
 
Reported: 2012-04-03 15:54 EDT by David van Balen
Modified: 2014-08-27 18:09 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 810911 (view as bug list)
Environment:
Last Closed: 2014-08-27 18:09:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
agent.log showing result of "plugins update" operations -- see 2012-04-03 11:14:23,535 (2.38 MB, text/x-log)
2012-04-03 15:54 EDT, David van Balen
no flags Details

  None (edit)
Description David van Balen 2012-04-03 15:54:42 EDT
Created attachment 574939 [details]
agent.log showing result of "plugins update" operations -- see 2012-04-03 11:14:23,535

Description of problem: Running certain agent prompt commands through the "Execute Prompt Command" option in the server UI (e.g. "plugins update") is reported as having failed with the stack-trace below, even though the command appears to have been executed successfully, based on the agent's log file.

java.lang.RuntimeException: Call to [org.rhq.plugins.agent.AgentServerComponent.invokeOperation()] with args [[executePromptCommand, Configuration[id=10241]]] was rudely interrupted.
	at org.rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler.invokeInNewThreadWithLock(ResourceContainer.java:479)
	at org.rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler.invoke(ResourceContainer.java:461)
	at $Proxy55.invokeOperation(Unknown Source)
	at org.rhq.core.pc.operation.OperationInvocation.run(OperationInvocation.java:217)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.InterruptedException
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1042)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
	at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:257)
	at java.util.concurrent.FutureTask.get(FutureTask.java:119)
	at org.rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler.invokeInNewThreadWithLock(ResourceContainer.java:473)
	... 6 more

Version-Release number of selected component (if applicable):

JON Server 3.0.0.GA and Agent  4.2.0.JON300.GA

How reproducible: Always


Steps to Reproduce:
1. Install server and agent.
2. Import agent into server inventory
3. Click on "Operations" tab for agent.
4. Schedule a new "Execute Prompt Command" operation and set the prompt command to be "plugins update"
5. Notice that the operation is listed as having failed under "History" in the server UI, but the agent's agent.log appears to show it as having succeeded.
  
Actual results: Successful operation reported as unsuccessful on server.


Expected results: If the operation was executed successfully, the status for the operation should reflect this.


Additional info: I tried setting the "Timeout" value to 30 seconds when scheduling the operation, but the status still shows up as "Failed" immediately after scheduling the operation (operation was scheduled as "Now").
Comment 1 Charles Crouch 2012-04-09 11:52:44 EDT
Removing from rhq tracker, and raised upstream rhq bug #810911, to try to reproduce
Comment 2 John Mazzitelli 2012-04-10 14:01:31 EDT
I think this is because updating plugins requires the plugin container to shutdown and restart.  Due to the shutdown, I think this will happen.

To work around this, we could try to update the plugins asynchronously, allowing the operation invokation method to return immediately with a success code.
Comment 3 John Mazzitelli 2012-04-10 14:05:58 EDT
(In reply to comment #2)
> I think this is because updating plugins requires the plugin container to
> shutdown and restart.  Due to the shutdown, I think this will happen.
> 
> To work around this, we could try to update the plugins asynchronously,
> allowing the operation invokation method to return immediately with a success
> code.

Hmm... looking at the code, it seems like it is preparing itself for the PC shutdown. Not sure why this bug is happening.
Comment 4 David van Balen 2012-04-10 16:13:33 EDT
According to bug 692933 (listed as a "See Also"), the same thing apparently happens when running stopping the plugin container (pc stop).
Comment 5 John Mazzitelli 2012-04-10 16:25:20 EDT
(In reply to comment #4)
> According to bug 692933 (listed as a "See Also"), the same thing apparently
> happens when running stopping the plugin container (pc stop).

yeah, anything that kills the plugin container needs to be handled special. Because the plugin is the thing that handles the operation invocation, and if the operation kills the plugin container, its killing the very same thing that is handling the operation :)
Comment 6 David van Balen 2012-04-10 16:28:43 EDT
Makes sense :)
Comment 7 John Mazzitelli 2012-04-10 17:14:29 EDT
oh, you know, I just realized this BZ is talking about the "Execute Prompt Command" !

Yes, in that case, this is definitely to be expected. Rather than use "plugins update" prompt command, you should directly invoke the "Update All Plugins" operation (this performs the "plugins update" asynchronously). Same thing with the "pc" command - there is a "Restart Plugin Container" operation to use instead.

Note that it doesn't make sense to do a remote "pc stop" because that will effectively make the agent dead in the water since once you stop the PC you can't remotely start it back up again (because the PC is down! It can't service any more remote calls like "pc start")

I think we should close this as WONTFIX. The behavior is to be expected simply by the nature of the prompt command attempting to be executed. We already have a "Update All Plugins" operation you can use to do this plugin update so there is no need to use Execute Prompt Command here.
Comment 8 John Mazzitelli 2012-04-10 17:45:14 EDT
if we want to avoid users doing this, I can change the Execute Prompt command operation implementation to look at the command being invoked and if its one of the commands that kill the PC, I can fail with an error message saying something like "don't do that".

This would be things like:

plugins update
pc restart
shutdown
pc stop

We have analogous first-class operations on the RHQ Agent that lets you do this already:

Update All Plugins
Restart Plugin Container
Shutdown Agent

We don't have anything analogous to "pc stop", but this is really not for production usage anyway - the "pc stop" command was for developers to use during debugging.
Comment 9 David van Balen 2012-04-10 18:38:14 EDT
I was actually thinking of requesting something like. I think having a more descriptive error message would go a long way, in this case.
Comment 10 bkramer 2012-05-28 09:59:29 EDT
The same exception will happen when executing "inventory --sync" as "Execute Prompt Command".

Note You need to log in before you can comment on or make changes to this bug.