Announcement Announcement Module
No announcement yet.
Persisting messages with a ChannelInterceptor Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Persisting messages with a ChannelInterceptor

    I am implementing ChannelInterceptor which persists the messages of queue channels. When the application is restarted I automatically restore the messages from the DB. The interceptor is supposed to persist the message when it arrives in the channel (I used the preSend Method), and update the state in the DB to “processed” when the message has been processed by the handler and sent to the next channel.

    Now I’ve seen, that the postReceive is called after the Handler has processed the Message but before the next channel has received the Message. This can be a problem for me, because the message may not be restored correctly if the message fails to persist in the following channel. I couldn’t find documentation when methods of the ChannelInterceptors exactly are called. So if I’m missing something or if somebody could give me a hint how to handle this problem, that would be great.

    Last edited by Ta0; Feb 24th, 2010, 05:23 AM.

  • #2
    In order to persist messages as they sit on the channel I would provide an implementation of PollableChannel or SubscribableChannel rather than attempt to use an interceptor to add this persistence to another channel implementation.

    This is how the JMS channel implementation that will be included in SI 2.0 works. By using this you get persistence if your broker is configured to provide that.

    There is also a blog here on a DB backed channel implementation

    Spring Integration 2.0 M3 will also provide inbound and outbound JDBC adapters which may be of interest.

    If this does not fit for you maybe you can explain what it is you are trying to achieve a little more.


    • #3
      We actually have three requirements:

      1. Guaranteed delivery
      2. Monitoring/Controlling (full message-level audit trail including the payload, the channel, time etc.)
      3. Resubmission (if processing of the message fails in one stage, the administrator can manually resubmit it starting in any previous stage of the process)

      As far as I can see the JMS Channel would meet requirement 1. But I probably still would have to implement a ChannelInterceptor for Requirements 2. and 3. Maybe this still is the better solution because I donít have to worry about restoring messages in the channels.

      Currently I made a hack, that the ChannelInterceptor adds the ID of the persisted Message to the Header, so that the following call of an Interceptor can a) change the state and b) add a reference to the preceding message to the current message which again is persisted. I guess something like this still would be necessary to build the audit trail.