Announcement Announcement Module
Collapse
No announcement yet.
Setting deferred delivery on a JMS message Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Setting deferred delivery on a JMS message

    Is it possible using Spring Integration, to setup a message which can be delivered at some future time, and simultaneouly, back it up with some DB message store or similar implementation? We want to run this in a cluster..

    I know, that weblogic producer has some JMS extension, which supports setting the deliverytime on the jms messages, and the JMSServer can be backed up by a persistent store, so that nothing is lost. This is what we are planning to implement, but that is specific to weblogic backed application only.

    To give a more background on the use case, we receive a quote (with a quoteId), which has some expiry time. This is inserted in a DB table.
    After we receive and pass back the quote-response to consumer, we need to do some rollbacks in case we don't receive any further action from end user, till the expiry time.
    Idea is, to have this message delivered at the expiry time, and once the listener receives it, validate if we have already received an action from consumer by then or not, and accordingly, do rollback or whatever else.

    Any other ideas for achieving this?

    Thanks

  • #2
    Hi spring gurus.. Any comments?

    Comment


    • #3
      What about QueueChannel with message-store

      Then you can have poller with some cron trigger set for certain time
      Code:
      <channel id="myChannel">
          <queue message-store="myMessageStore"/>
      </channel>
      Is that the use case?

      Comment


      • #4
        Hi Oleg

        In a day, we can receive hundreds / thousands of quotes for different currency pairs (with expiry time within 90 seconds). As per above mentioned aproach, I have to have those many dynamic cron triggers set, based on the expirytime. And the number will keep growing by days...

        Instead, what I want it, the message itself is put in a specific channel / queue at the specified time without use of any cron based poller. At the same time, the message should be stored / backed up in some DB table till the delivery time.

        Please see this:
        http://www.theserverside.com/discuss...d=41364#213837

        Coming back to your suggestion, retrieving from the table and sending at a specified time is what seems like the problem is.

        May be I write a process, which continously keeps checking the table rows, and mark them as processed in a seperate column as soon as a message has been created and sent for that row. Problem might be, when number of rows grow large (even if rows are indexed on "processed" column)... Is that what you are thinking?

        Comment


        • #5
          Well first of all I would not worry about many triggers and/or channels. Weblogic must have some kind or trigger mechanisms for each message, at least that would be the right way to do and they are not expensive objects to create nor do they take any significant memory.

          We also have this issue open for 2.1 https://jira.springframework.org/browse/INT-1132
          The approach discussed there is a bit different since it describes a special Delay Handler which itself is aware of when to release certain messages, which could probably be handle by a single trigger which has a static list of next execution times and reference to a message that has to be released at that time.
          Would be interesting to know your thoughts.

          Comment


          • #6
            Also

            I want to clarify one thing. I might have made it sound like its a new feature we are trying to have. We actually have this feature available in Spring Integration since 1.0.3. Its called DelayHandler
            http://static.springsource.org/sprin...ingle/#delayer
            which essentially grabs a Message and delays its release to the next channel based on the value provided in the delay header (you can specify your one delayHeaderName).
            One of the properties of the DelayHandler is messageStore which is there to make sure that Messages are not lost.

            The JIRA issue i pointed out to you earlier is actually related to how to handle delay time if the server was down for a while. For example. Lets say you have a message that needs to be delayed for 15 min. When 10 minutes went by the server crashed.
            Now you have two scenarios;
            1. The server was restarted 3 min later. Should the delay time be reset to 15 min? Or should it be 2 min (5-3=2)?
            2. The server was restarted 30 hours later. Should the delay time be reset to 15 min or should the handler be smart enough to see that this message should have been released hours ago?
            etc...
            In any event, let me know what you think but also try the DelayHandler as it has all of the functionality you need less what i described up above.

            Comment


            • #7
              The DelayHandler might serve the purpose, if it supports the continuation from where it left, after restart in case of JVM crash.

              it describes a special Delay Handler which itself is aware of when to release certain messages, which could probably be handle by a single trigger which has a static list of next execution times and reference to a message that has to be released at that time
              From the DelayHandler source code, I see that a new Runnable is scheduled using taskScheduler. How is this going to persist across JVM crash and restarts, is that the jira about?

              I am going to take a deeper look at this right away, and from what I see from the jira and javadocs, it looks like this should fulfill my use case, *IF* the jira is resolved soon.

              Any tentative idea about when this is targeted to fix? I would really love to see this in 2.0.2 if possible at all! My use case is a strong one, if you agree

              On a side note, the weblogic implementation is simple and straightforward, but we don't want to tie up the solution with a particular platform.

              Comment


              • #8
                well, our paths just crossed it seems...

                Comment


                • #9
                  Yes, the issue is exactly about the scenario you describing. Server crashes.
                  So having said that I have a few questions.
                  Earlier I've described these scenarios:
                  ..you have a message that needs to be delayed for 15 min. When 10 minutes went by the server crashed.
                  1. The server was restarted 3 min later. Should the delay time be reset to 15 min? Or should it be 2 min (5-3=2)?
                  2. The server was restarted 30 hours later. Should the delay time be reset to 15 min or should the handler be smart enough to see that this message should have been released hours ago?
                  What behavior would you expect?


                  Also, could you please explain your use case. This is purely to satisfy our curiosity. Why does your system produce Message that is not ready to be processed?

                  Comment


                  • #10
                    I will start with this:

                    Why does your system produce Message that is not ready to be processed?
                    In the very first post I tried to explain the use case:
                    1. Consumer requests for a Quote
                    2. Our application goes to some back-end system to retrieve live quote, which is valid till, lets say, time t1.
                    3. Update DB Tables with appropriate details of the quote etc ...
                    3. Give the quote back to Consumer.

                    If consumer doesn't take any action till t1, we need to go back to back-end system, and cancel the quote.

                    We are thinking of creating a message with delivery time set as t1, and inserting in a new table, and mark as unprocessed.

                    -If consumer acts before t1, that message would be marked as processed in Table (if not done already), and normal business flow would continue.
                    (so when DelayHandler delivers the message at t1, its already marked as processed, and no action would be taken)

                    -If no response from consumer till t1, DelayHandler will deliver the message at t1 as expected, and we will mark the message processed, and call rollback etc....

                    Does this clarify the use case ?

                    Coming to the question about:
                    ..you have a message that needs to be delayed for 15 min. When 10 minutes went by the server crashed.
                    1. The server was restarted 3 min later. Should the delay time be reset to 15 min? Or should it be 2 min (5-3=2)?
                    2. The server was restarted 30 hours later. Should the delay time be reset to 15 min or should the handler be smart enough to see that this message should have been released hours ago?
                    If server was restarted and came back up before t1, we want the system to behave as if, nothing happened. That means, the DelayHandler should still deliver the message at t1. (Relating to your 1st statement above, the new delay time should be now 2 min)

                    If server was restarted after t1, in that case, Delayhandler should send the corresponding messages as soon as the context is up (as t1 has already passed).

                    Idea is, we have to go back to backend system with some action by concrete time: t1
                    Either its rollback (in case of no user action or Quote expiration) *OR* normal business flow (if user accepts / rejects the quote)

                    Please let me know, if this answers your questions.
                    Last edited by GPS; Dec 23rd, 2010, 02:19 PM.

                    Comment

                    Working...
                    X