Thomas, thanks for that note, I hadn't noticed
ComponentInvocationContext#isInterrupted. Still, I think the best
solution now is probably to emulate the script plugin's "execute"
operation, so that we have some consistency. Instead of worrying about
the interaction between operationTimeout and
ProcessExecution#setWaitForCompletion, just ignore the former and defer
to the latter.
On 2/21/2014 5:14 AM, Thomas Segismont wrote:
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
>
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel