Bug 1054360 - RFE: let users run an AS7/EAP6 CLI script with an operation on Standalone or Host Controller resources

Jay Shaughnessy jshaughn at redhat.com
Wed Feb 19 19:02:11 UTC 2014


>> But there already is timeout for operations. Is there a way to get to 
>> this value at runtime on agent side within operation code? I am only 
>> able to get to default value using ResourceType.
>
> I think there was some work done by Thomas S to use that timeout in 
> other places. If that timeout is not yet
> available inside the plugin code, we should expose it 

Today we specifically hide that information from the plugin code. And 
the ultimate value used for the operation timeout has 4 potential 
values:  The value set by the user for that operation invocation, the 
value set in the operation metadata, the setting of 
rhq.pc.operation-invocation-timeout or finally, the default of 600s (5 
minutes).  If we did expose it we'd have to pass it as a "special" 
operation parameter, I think.

This issue right now is that we don't expose it to the plugin code (and 
I'm still not sure that we should) and we also don't provide any 
mechanism to kill a process spawned by the plugin's invokeOperation code 
(I'm assuming the process would be spawned by 
SystemInfo.executeProcess(ProcessExecution)).

If you really want to tie the spawned processed life to the operations 
timeout value then I think the correct way to do things would be to have 
the invokeOperation() impl handle the InterruptedException generated by 
the plugin container and then destroy the Process in that handling 
code.  Doing this would mean we'd to provide a hook to get the spawned 
process.

if you want the spawned process to run independently of the operation's 
timeout, possible living a shorter or longer life, then I think the 
timeout for the process should be specified as an operation parameter 
and then supplied to processExecution.setWaitForCompletion();

> For now I've hardcoded 60 seconds and pushed to master.

As mentioned above, I don't think this value should be hardcoded. If 
nothing else changes I think it should be an operation parameter.

Libor, note that I see in your code that you are setting 
processExecution.setWaitForCompletion(60*1000).  You are *not* setting 
processExecution.setKillOnTimeout(true);  That means that the call to 
spawn the process will return (likely a null exitCode) but the spawned 
process will live on as long as it likes.  Is that what you want to have 
happen?

So, I guess it is up for debate still what is best.  If we want to 
expose the operation's timeout to the underlying operation code we 
could, but I'm not sure we should because that timeout already triggers 
an InterruptedException that the plugin code can optionally handle.   If 
we want to provide a hook to allow allow a spawned process to be 
destroyed we could [1] and then the interrupt handling code could 
destroy it.

thoughts?

[1] I think we could do this by adding ProcessExecution.set/getProcess() 
methods. SystemInfo.executeProcess(ProcessExecution) could set the 
process as  soon as it gets spawned. So even if the the call to 
executeProcess() has yet to return, we could access the process in the 
caller if we get interrupted.



More information about the rhq-devel mailing list