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
--
Libor Zoubek