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
Fri Feb 21 14:38:05 UTC 2014


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#3001
>
> Le 20/02/2014 17:39, Libor Zoubek a écrit :
>> Dne Wed, 19 Feb 2014 20:02:11 +0100 Jay Shaughnessy
>> <jshaughn at 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 at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list