Announcement Announcement Module
No announcement yet.
Using a Delayer with our own message store implementation Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using a Delayer with our own message store implementation


    I'm using a delayer together with a specialized message store implementation (2.2.1.RELEASE).

    Now the DelayHandler class wraps a message to delay into an instance of DelayedMessageWrapper which is a private static inner class of the DeplayHandler. This is somewhat unfunctional, because one cannot get / inspect the wrapped message.

    The wrapper simply adds a request date to determine the release date. Why not simply add a header to the message?

    Or make the DelayedMessageWrapper a normal public class not an inner private class.

    Regards Stefan

  • #2
    I'll let Cleric answer but I believe we don't want to mutate the message just because we delayed it (headers are immutable).

    So, yes, it should be visible for use cases like yours.

    It's ugly, but you could use a DirectFieldAccessor for now.


    • #3
      Hi, Stefan!
      DelayedMessageWrapper is an internal holder and indicator for Message which was delayed already.
      Make the same with header may not have a value for Delayer internally.
      We use the same technique for MondoDB: MongoDbMessageStore.MessageWrapper.
      From other side, can you explain a reason to access to delayed Messages? Why do you introduce your own 'specialized message store implementation'?
      Maybe there is any other solution?
      We strongly don't recommend to use internal API (e.g. MessageStore) for business requirements.

      Take care,


      • #4
        And yes, Gary is right: DelayHandler implements AbstractReplyProducingMessageHandler, so if we add a 'requestDate' it will be send with reply Message: we can't remove it within DelayHandler. But if you have a cascad of delyaers...


        • #5
          So, I looked at this more and I agree: DelayedMessageWrapper should be public - now there is no ability to browse Message from Store with this type, because it is a serialization from. And there maybe no any business requirements. It's just traceability and friendliness from framework.
          Feel free to open an improvement issue:


          • #6
            Hi Cleric,

            I've opened

            The reason we introduced an extension to the original JDBCMessageStore is simply transparency. Especially for a delayed message it is useful to know what kind of message is hold by a delayer. so our extension adds some redundant database fields that gives some extra information about the stored messages.