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