[
https://issues.apache.org/jira/browse/EXEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Dubinsky updated EXEC-96:
-----------------------------------
Description:
DefaultExecutor handles InterruptedException while waiting for the process to
finish executing by killing the process and setting the error code to
INVALID_EXITVALUE. This behavior isn't documented. It would be better if it
threw an InterruptedExecuteException or an InterruptedIOException. This would
clearly communicate the reason that execution failed. Also, it should throw
this exception even if exitValues is null.
In Java 8 there is a new method Process.destroyForcibly. I haven't used it, but
I wonder if it may be appropriate to call it instead of destroy.
I tried to understand how thread interruption would affect the other operations
in executeInternal, particularly streams.stop. I'm not sure if that works
correctly. It seems to swallow the InterruptedException, interrupts the pump
thread which may lead to data loss, then proceeds as normal. The caller needs
to be informed that the operation failed with an exception. Also, after an
interruptedexception is received, the pumpstreamhandler should not try to
orderly close the other threads.
I didn't go through the whole source code, but there's probably other areas
that need correct InterruptedException handling.
was:
DefaultExecutor handles InterruptedException while waiting for the process to
finish executing by killing the process and setting the error code to
INVALID_EXITVALUE. This behavior isn't documented. It would be better if it
threw an InterruptedExecuteException or an InterruptedIOException. This would
clearly communicate the reason that execution failed. Also, it should throw
this exception even if exitValues is null.
In Java 8 there is a new method Process.destroyForcibly. I haven't used it, but
I wonder if it may be appropriate to call it instead of destroy.
I tried to understand how thread interruption would affect the other operations
in executeInternal, particularly streams.stop. I'm not sure if that works
correctly. It seems to swallow the InterruptedException, but I don't know how
likely it is to block for any length of time. Nevertheless, if it's not going
to re-throw the InterruptedException, it should set the interrupted flag.
> When execution is interrupted, an exception should be thrown
> ------------------------------------------------------------
>
> Key: EXEC-96
> URL: https://issues.apache.org/jira/browse/EXEC-96
> Project: Commons Exec
> Issue Type: Improvement
> Affects Versions: 1.3
> Reporter: Aleksandr Dubinsky
>
> DefaultExecutor handles InterruptedException while waiting for the process to
> finish executing by killing the process and setting the error code to
> INVALID_EXITVALUE. This behavior isn't documented. It would be better if it
> threw an InterruptedExecuteException or an InterruptedIOException. This would
> clearly communicate the reason that execution failed. Also, it should throw
> this exception even if exitValues is null.
> In Java 8 there is a new method Process.destroyForcibly. I haven't used it,
> but I wonder if it may be appropriate to call it instead of destroy.
> I tried to understand how thread interruption would affect the other
> operations in executeInternal, particularly streams.stop. I'm not sure if
> that works correctly. It seems to swallow the InterruptedException,
> interrupts the pump thread which may lead to data loss, then proceeds as
> normal. The caller needs to be informed that the operation failed with an
> exception. Also, after an interruptedexception is received, the
> pumpstreamhandler should not try to orderly close the other threads.
> I didn't go through the whole source code, but there's probably other areas
> that need correct InterruptedException handling.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
