Hi Libor,
The thread became quite long so forgive me I'll sum up instead of
replying to each point:
* don't try to stop the script execution after timeout (in the thread
Larry gave the reasons not to do this)
* read OperationFacet Javadoc: since RHQ 4.9, you can rely on
ComponentInvocationContext#isInterrupted [1] to detect timeout and
cancellation
If you're curious, OperationManager#getOperationTimeout has the logic to
determine the operation timeout (taking into account default or
overridden value). But again, in your case, you don't need to know what
the value is, you need to know *when* the invocation is interrupted
(ComponentInvocationContext#isInterrupted)
Regards,
Thomas
[1] more on this in this thread
https://lists.fedorahosted.org/pipermail/rhq-devel/2013-July/thread.html#...
Le 20/02/2014 17:39, Libor Zoubek a écrit :
Dne Wed, 19 Feb 2014 20:02:11 +0100 Jay Shaughnessy
<jshaughn(a)redhat.com> napsal(a):
> 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?
I overlooked processExecution.setKillOnTimeout(true);. I was not sure
about what I wanted. It is AS7 CLI script which may run longer then
operation timeout or hardcoded timeout. Killing that process could cause
AS to get misconfigured or partially configured. Letting it live might
be good in this case, as I don't except it to hang. I know hardcoded
value is wrong solution. I just didn't want to introduce another
parameter just for handling spawned process timeout and I wanted to make
this feature to 4.10, timeout could be fixed later, when I find out a
better way. I was hoping this was kind of sorted out in other plugins.
> 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?
I like the idea of handling InterruptedException. In this code I can
could read process output (that would be partial at that time) and
report operation failure with partial response. But .. I'd have to set
processExecution.setWaitForCompletion to +infinite, because I never want
to hit procesExecution timeout.
Is it possible to do it now this way? Or does it need some changes in PC
or ProcessExecution?
> [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.
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel