Petals ESB Container

During/After SU shutdown (aka endpoint deactivation), reinject new exchanges left in the DeliveryChannel into the NMR

Details

  • Type: Improvement Request Improvement Request
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.0.0
  • Fix Version/s: 5.0.2
  • Component/s: Router
  • Security Level: Public
  • Description:
    Hide

    Currently, if there is exchanges still in the queue of the DeliveryChannel when a SU Provides after shut down (i.e., after its endpoint is deactived from the container POV), these messages are simply lost.

    Like with PETALSESBCONT-379, for the new exchanges (those that are not answers to previous exchanges), it would make sense to reinject them in the router because:

    • either there is other provider that can answer them.
    • either there is not and the consumer should get an error for its request.

    For non-new exchanges, they should still be handled by the component.
    After undeploy, an error should be returned to the sender.

    This goes in the way to improve the reliability of the container for message delivery (PETALSDISTRIB-146).

    Show
    Currently, if there is exchanges still in the queue of the DeliveryChannel when a SU Provides after shut down (i.e., after its endpoint is deactived from the container POV), these messages are simply lost. Like with PETALSESBCONT-379, for the new exchanges (those that are not answers to previous exchanges), it would make sense to reinject them in the router because:
    • either there is other provider that can answer them.
    • either there is not and the consumer should get an error for its request.
    For non-new exchanges, they should still be handled by the component. After undeploy, an error should be returned to the sender. This goes in the way to improve the reliability of the container for message delivery (PETALSDISTRIB-146).
  • Environment:
    -

Issue Links

People

Dates

  • Created:
    Fri, 22 Jan 2016 - 15:39:39 +0100
    Updated:
    Fri, 27 May 2016 - 10:55:37 +0200
    Resolved:
    Fri, 27 May 2016 - 10:55:36 +0200