[
https://issues.apache.org/jira/browse/DERBY-5444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121419#comment-13121419
]
Kristian Waagan commented on DERBY-5444:
----------------------------------------
I don't know of any use cases for the interrupt handling introduced by the
patch currently. Restoring the interrupted status seemed more reasonable than
swallowing them, as it gives the caller a chance to detect that the thread has
been interrupted (i.e. Thread.interrupted or Thread.isInterrupted).
The patch raises an exception if the thread is interrupted while waiting for
the spawned process to die. I'll do another pass and improve the error handling.
Off the top of my head, maybe the following:
o method sleep: ignore interrupt, allow premature wakeup, leave interrupted
status cleared
o javaProcess.waitFor: throw exception, leave interrupted status cleared
o xSaver.join: not sure about this one. Would it be best to retry, or simply
continue (as with current patch)?
As you say, I don't think the test framework will interrupt the thread in the
normal case. The reason for not restoring the interrupted flag in the cases
were we don't handle it must be that it can cause other code to fall over, i.e.
IO calls in another unrelated test. The caller probably can't do anything to
recover from the interrupts, so it would maybe be better to swallow them after
all (except for in the javaProcess.waitFor case).
> SpawnedProcess.complete may fail to destroy the process when a timeout is
> specified
> -----------------------------------------------------------------------------------
>
> Key: DERBY-5444
> URL: https://issues.apache.org/jira/browse/DERBY-5444
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.9.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-5444-1a-destroy_on_timeout.diff
>
>
> The logic in SpawnedProcess has a weakness that may result in the wrapped
> process not being destroyed if the destroy variable is false and a timeout is
> specified.
> The problem is that the while condition will shortcut the if condition in the
> catch clause (where destroy is set to true if the timeout is exceeded).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
