Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 2.2 M4
    • Component/s: None
    • Labels:
      None

      Description

      A way to do retry logic is to set a custom error channel and increment a retry count header on the message before putting it back on the queue. A router can then decide to move the message off to the dead letter channel when a retry limit is reached. This is possible to do manually now, but the router and transformer involved could be part of the framework.

      This issue is aimed to accommodate the async variant of INT-343.

        Activity

        Hide
        Iwein Fuld added a comment -
        Show
        Iwein Fuld added a comment - http://forum.springframework.org/showthread.php?t=68172 is relevant too
        Hide
        Mark Fisher added a comment -

        assigning to you, Gary since it's related to INT-343

        If you feel this is already covered by Delayer (this issue precedes that), feel free to close it.

        Show
        Mark Fisher added a comment - assigning to you, Gary since it's related to INT-343 If you feel this is already covered by Delayer (this issue precedes that), feel free to close it.
        Hide
        Gary Russell added a comment -

        This issue is resolved by using spring-retry in the resolution to INT-343. Spring retry supports stateless (synch) and stateful (asynch) retry with pluggable policies. With stateful retries, configurable state is maintained so that, during resubmission, the framework can decide when retries are exhausted and call recovery code, that can dispose of the message as required.

        Show
        Gary Russell added a comment - This issue is resolved by using spring-retry in the resolution to INT-343 . Spring retry supports stateless (synch) and stateful (asynch) retry with pluggable policies. With stateful retries, configurable state is maintained so that, during resubmission, the framework can decide when retries are exhausted and call recovery code, that can dispose of the message as required.

          People

          • Assignee:
            Gary Russell
            Reporter:
            Iwein Fuld
          • Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: