Wicket
  1. Wicket
  2. WICKET-3893

Possible deadlock running AsynchronousDataStoreTest

    Details

    • Type: Test Test
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None

      Description

      Running AsynchronousDataStoreTest on "slow" pc (i.e. dual core 2 GhZ, 2 Gb of ram) AsynchronousDataStoreTest doesn't terminate at all. I think that problem occurs when we submit a task which has been already submitted but not executed yet. This leads to a missed latch countdown.
      The problem doesn't occur when I decrease EXECUTIONS variable.

      A possible fix is to replace latch with a calling to awaitTermination method.

      I attach a patch.

        Activity

        Hide
        Martin Grigorov added a comment - - edited

        I started facing this problem just this morning, and it happened only when I built with bg_BG locale. en_US always worked. The previous days this never blocked. And I build mostly with bg_BG locale...
        Your fix doesn't solve the problem because it just ignores the uncompleted tasks. See the result of .awaitTermination() - it always returns 'false'.

        I tried to improve it but so far the only way to fix it is to restore the previous version of AsynchronousDataStore.

        Show
        Martin Grigorov added a comment - - edited I started facing this problem just this morning, and it happened only when I built with bg_BG locale. en_US always worked. The previous days this never blocked. And I build mostly with bg_BG locale... Your fix doesn't solve the problem because it just ignores the uncompleted tasks. See the result of .awaitTermination() - it always returns 'false'. I tried to improve it but so far the only way to fix it is to restore the previous version of AsynchronousDataStore.
        Hide
        Andrea Del Bene added a comment -

        Hi Martin,

        that's quite strange. I've tried my code changing locale (I've also tried 'Locale.setDefault(new Locale("bg_BG"));') and increasing EXECUTIONS up to 1 million without any problem.
        awaitTermination always returned 'true'.

        Do you think that Locale could affect AsynchronousDataStoreTest execution?

        Show
        Andrea Del Bene added a comment - Hi Martin, that's quite strange. I've tried my code changing locale (I've also tried 'Locale.setDefault(new Locale("bg_BG"));') and increasing EXECUTIONS up to 1 million without any problem. awaitTermination always returned 'true'. Do you think that Locale could affect AsynchronousDataStoreTest execution?
        Hide
        Martin Grigorov added a comment -

        I don't think so.
        By the way the valid way is : new Locale("bg", "BG").

        If I move "LATCH.countDown()" before the execution of r() then it passes. But it is incorrect because this way the runnable may not finish its work. As what happens with awaitTermination() when it returns 'false'.

        But the question is why some of the runnables doesn't decrement the latch ? If the runnable is rejected then I expect to see thrown RejectedExecutionException's.
        It seems AsynchronousDataStore's ThreadPoolExecutor blocks for some reason.

        Show
        Martin Grigorov added a comment - I don't think so. By the way the valid way is : new Locale("bg", "BG"). If I move "LATCH.countDown()" before the execution of r() then it passes. But it is incorrect because this way the runnable may not finish its work. As what happens with awaitTermination() when it returns 'false'. But the question is why some of the runnables doesn't decrement the latch ? If the runnable is rejected then I expect to see thrown RejectedExecutionException's. It seems AsynchronousDataStore's ThreadPoolExecutor blocks for some reason.
        Hide
        Andrea Del Bene added a comment -

        I've tried with new Locale("bg", "BG") and test still runs good.
        In my patch I've completely removed LATCH because if you use awaitTermination you don't need it anymore.

        I think that some runnables doesn't decrement latch because they are submitted twice or more before they are executed. When this happens the Runnable is executed only once , even if you have submitted it twice or more.
        The bigger is EXECUTIONS the more you should note this behavior.

        Show
        Andrea Del Bene added a comment - I've tried with new Locale("bg", "BG") and test still runs good. In my patch I've completely removed LATCH because if you use awaitTermination you don't need it anymore. I think that some runnables doesn't decrement latch because they are submitted twice or more before they are executed. When this happens the Runnable is executed only once , even if you have submitted it twice or more. The bigger is EXECUTIONS the more you should note this behavior.
        Hide
        Andrea Del Bene added a comment -

        Unfortunately I didn't find much documentation about re-submitting of Runnable already queued inside an Executor

        Show
        Andrea Del Bene added a comment - Unfortunately I didn't find much documentation about re-submitting of Runnable already queued inside an Executor
        Hide
        Martin Grigorov added a comment -

        Pedro fixed it with WICKET-3900.

        Show
        Martin Grigorov added a comment - Pedro fixed it with WICKET-3900 .

          People

          • Assignee:
            Unassigned
            Reporter:
            Andrea Del Bene
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development