Derby
  1. Derby
  2. DERBY-5444

SpawnedProcess.complete may fail to destroy the process when a timeout is specified

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: 10.8.2.2, 10.9.1.0
    • Component/s: Test
    • Labels:
      None

      Description

      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).

      1. derby-5444-1a-destroy_on_timeout.diff
        4 kB
        Kristian Waagan
      2. derby-5444-1b-destroy_on_timeout.diff
        4 kB
        Kristian Waagan
      3. derby-5444-1c-destroy_on_timeout.diff
        2 kB
        Kristian Waagan

        Activity

        Hide
        Kristian Waagan added a comment -

        Closing issue.

        Show
        Kristian Waagan added a comment - Closing issue.
        Hide
        Kristian Waagan added a comment -

        Myrna, I backported the fix to the 10.8 branch with revision 1180817.

        Show
        Kristian Waagan added a comment - Myrna, I backported the fix to the 10.8 branch with revision 1180817.
        Hide
        Myrna van Lunteren added a comment -

        Would this be suitable for back port to the 10.8 branch?

        Show
        Myrna van Lunteren added a comment - Would this be suitable for back port to the 10.8 branch?
        Hide
        Kristian Waagan added a comment -

        Thanks for the reviews, Dag.

        Resolving issue.
        I don't expect to do more work here.

        Show
        Kristian Waagan added a comment - Thanks for the reviews, Dag. Resolving issue. I don't expect to do more work here.
        Hide
        Kristian Waagan added a comment -

        Attaching patch 1c, which only fixes the loop logic.

        I went a bit back and forth on the handling of InterruptedException, and decided to change nothing. SpawnedProcess is mostly used in setUp and tearDown methods anyway, and they are usually defined to throw Exception.

        As far as I understand, only Object.wait is subject to spurious wakeups, so in the other cases another thread must have explicitly interrupted the sleeping/working thread.

        Committed 1c to trunk with revision 1179546.

        Show
        Kristian Waagan added a comment - Attaching patch 1c, which only fixes the loop logic. I went a bit back and forth on the handling of InterruptedException, and decided to change nothing. SpawnedProcess is mostly used in setUp and tearDown methods anyway, and they are usually defined to throw Exception. As far as I understand, only Object.wait is subject to spurious wakeups, so in the other cases another thread must have explicitly interrupted the sleeping/working thread. Committed 1c to trunk with revision 1179546.
        Hide
        Dag H. Wanvik added a comment -

        Thanks, Kristian. I think, if we don't expect any interrupts to happen that it's good to just fail the test, since probably it would be assign that something else is wrong - better to fail early. I see now you ignore it in two cases: sleep (where it doesn't really matter as you say) and while waiting for the two streamsavers to terminate. You throw in the case where we get interrupted before we are able to see the spawned process terminate and get its error code. I guess that protects the main functionality, but I think I'd prefer throwing in the other two cases as well (from the fail early principle). Unless you can see a reason it would be good to continue here? But that is just my preference, your call.
        +1 in any case.

        Show
        Dag H. Wanvik added a comment - Thanks, Kristian. I think, if we don't expect any interrupts to happen that it's good to just fail the test, since probably it would be assign that something else is wrong - better to fail early. I see now you ignore it in two cases: sleep (where it doesn't really matter as you say) and while waiting for the two streamsavers to terminate. You throw in the case where we get interrupted before we are able to see the spawned process terminate and get its error code. I guess that protects the main functionality, but I think I'd prefer throwing in the other two cases as well (from the fail early principle). Unless you can see a reason it would be good to continue here? But that is just my preference, your call. +1 in any case.
        Hide
        Kristian Waagan added a comment -

        Patch 1b changes how InterruptedExceptions are handled; they are now either ignored (because it doesn't matter for SpawnedProcess), or an exception is raised.

        Running regressions now.
        Patch ready for review.

        Show
        Kristian Waagan added a comment - Patch 1b changes how InterruptedExceptions are handled; they are now either ignored (because it doesn't matter for SpawnedProcess), or an exception is raised. Running regressions now. Patch ready for review.
        Hide
        Kristian Waagan added a comment -

        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).

        Show
        Kristian Waagan added a comment - 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).
        Hide
        Dag H. Wanvik added a comment -

        Changes look good, just wondering, what is the test use case for the way interrupts are handled here? Is this code liable to be used in a context where
        the current thread is being interrupted? (since you turn them back on consistently - not that it should hurt)

        Show
        Dag H. Wanvik added a comment - Changes look good, just wondering, what is the test use case for the way interrupts are handled here? Is this code liable to be used in a context where the current thread is being interrupted? (since you turn them back on consistently - not that it should hurt)
        Hide
        Kristian Waagan added a comment -

        Attaching patch 1a, which includes the following changes:
        o don't throw InterruptedException when sleeping.
        This cluttered the calling code, and instead I restored the interrupted status of the thread and continued work.
        o rewrote loop/login in complete to make sure we always destroy the process if a timeout is specified and we indeed time out.
        o print a warning if we are interrupted while waiting for the output from the process to be gathered.

        Regression tests passed on Solaris11.
        Patch ready for review.

        Show
        Kristian Waagan added a comment - Attaching patch 1a, which includes the following changes: o don't throw InterruptedException when sleeping. This cluttered the calling code, and instead I restored the interrupted status of the thread and continued work. o rewrote loop/login in complete to make sure we always destroy the process if a timeout is specified and we indeed time out. o print a warning if we are interrupted while waiting for the output from the process to be gathered. Regression tests passed on Solaris11. Patch ready for review.

          People

          • Assignee:
            Kristian Waagan
            Reporter:
            Kristian Waagan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development