Announcement Announcement Module
No announcement yet.
Side effects of message history vs. stateful retry vs. jdbc store Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Side effects of message history vs. stateful retry vs. jdbc store


    we discovered a problem with stateful retry. We are using the jdbc based message store and as retry state generator the spel based one refering to the message id as the key to use.

    The problem is the MessageHistory class creates new messages everytime it appends an item to the history header. with stateful retry this results in an endless loop, because the retry advice sees a brand new message every new try

    The retry context is recreated every time and the retryCount never reaches maxAttempts.

    Another effect with jdbc message store: the store uses a header JdbcMessageStore.SAVED to mark messages that are already persisted. MessageHistory copies this header along with all other headers of the message. As a result the newly update message with the new history item will never persisted in the jdbc store

    Any suggestions what key we could use intead of the message id? Of couse we could create some key attribute in the message payload, but this is ugly.

    I think it should pointed out, that turning on the message history feature could cause side effects. At least with persistence and stateful retry. The actual documentation simply states:
    Therefore, when writing Message History values, the components are either creating brand new Messages (when the component is an origin), or they are copying the history from a request Message, modifying it and setting the new list on a reply Message.
    It is not that clear what kind of effects this could entail.

    Regards steve

  • #2
    I don't understand your comment about the SAVED_KEY header; that only prevents saving if the message (with the same id) already exists in the store.

    For the retry key, how about adding a header enricher that captures the message id at some point in the flow...

    <header-enricher ...>
        <header name="retryKey" expression=""/>


    • #3
      Thx Gary for the reply. You are right with the message store. The message didn't show up in the db because the transaction was always rollbacked in the stateful retry.

      I've thought about an extra header as retry key too, but we must create this additional header at every point in the flow with a retry advice. If a service activator creates a new message as reply, one must recreate the additional header again.


      • #4
        No, you only need to establish it once; the framework will propagate it whenever a component creates a new message. The only exception to this is a <transformer/> if the method returns a Message<?>, in which case the framework assumes the transformer has set up the headers it wants. However, even in that case (which is generally not recommended), it's easy to propagate the headers, using MessageBuilder.copyHeaders().