Spring Batch
  1. Spring Batch
  2. BATCH-537

Bad ItemKeyGenerator strategy can lead to infinite loop in retry

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0.0
    • Fix Version/s: 1.0.1
    • Component/s: Core
    • Labels:
      None

      Description

      Bad ItemKeyGenerator strategy can lead to infinite loop in retry. http://forum.springframework.org/showthread.php?t=51766 is a good example. Part of the problem here is that the skip limit is ignored when retry is in place (that's a bug as well).

        Activity

        Hide
        Dave Syer added a comment -

        Put some checks in ItemWriterRetryPolicy to try and detect hash codes that are inconsistent (it would be better to move that responsibility to the RetryContextCache, since the implementation might not be based on hash codes - leave that for future release).

        Also the MapRetryContextCache now has a maximum capacity, and throws an exception if it reaches that. This prevents the kind of basic error from the forum post where the hashCode of items is not consistent between calls to ItemReader.read(). The default capacity is 4096, so you have to wait quite a while before it fails by default, but at least it isn't an infinite loop. The capacity is for the whole cache, but it would be quite unusual for the limit to be reached in normal circs because failed items are removed when they are recovered.

        Also had to make sure RetryException was fatal for the ItemHandler in the retry step factory bean (through the step-level exception handler).

        Show
        Dave Syer added a comment - Put some checks in ItemWriterRetryPolicy to try and detect hash codes that are inconsistent (it would be better to move that responsibility to the RetryContextCache, since the implementation might not be based on hash codes - leave that for future release). Also the MapRetryContextCache now has a maximum capacity, and throws an exception if it reaches that. This prevents the kind of basic error from the forum post where the hashCode of items is not consistent between calls to ItemReader.read(). The default capacity is 4096, so you have to wait quite a while before it fails by default, but at least it isn't an infinite loop. The capacity is for the whole cache, but it would be quite unusual for the limit to be reached in normal circs because failed items are removed when they are recovered. Also had to make sure RetryException was fatal for the ItemHandler in the retry step factory bean (through the step-level exception handler).
        Hide
        Dave Syer added a comment -

        Assume closed as resolved and released

        Show
        Dave Syer added a comment - Assume closed as resolved and released

          People

          • Assignee:
            Dave Syer
            Reporter:
            Dave Syer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: