Announcement Announcement Module
Collapse
No announcement yet.
Aggregator Release Strategy Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Aggregator Release Strategy

    I am trying to implement a ReleaseStrategy method (annotated) in a POJO. I see that I can get a List of payload or Messages. I have an upstream Transformer that populates a CORRELATION_ID, but I do not have a sequence number or total that I now of. The adapter in this scenario is an inbound SFTP adapter that will pull files. the correlation is a part of the filename and that is handled in the transformer. The adapter may pull 100 files or it may pull 5 files at each polling interval, but I do not know, obviously. There are 3 correlations in this scenario.

    so, How can I know when to release ? I either need a Timer to say, it has been 30min or I need to know how many of a particular CORRELATION_ID there are in the Group and choose.

    return (timeElapsed() == RELEASE_EXPIRATION || list.size() == NUMBER_POLLED)

    Is my only option a splitter after the transformer and a aggregator that only manages a single correlation?



    Ideas?
    TIA
    -jc

  • #2
    Well, this is an interesting use case and thankfully supported
    In short you can release messages in groups of some arbitrary number (e.g., 5) and then also set a timeout using MesageStoreReaper for when to clean up the remaining.
    I've covered this exact use case in my latest webinar.
    Here is the code https://github.com/olegz/s12gx.2011/...ion/aggregator
    and here is the webinar link: http://www.youtube.com/watch?v=9O2BW...1&feature=plcp

    Comment


    • #3
      Now I am thinking it might be good to tie a/the reaper to a shutdown hook or would expiration take car of that....

      Comment


      • #4
        Good point.

        2.2.0.M1 has some initial work for performing orderly shutdown. Many use cases are covered, but we recognized there are other things needed for a complete solution; this is one of those things - the shutdown should somehow force the reaper to run before shutting down the executors.

        Please either add a comment to https://jira.springsource.org/browse/INT-2515, or open a new JIRA and we'll make it a subtask of that one.

        Comment


        • #5
          Thanks for the (typical) rapid response
          I have been thinking, in our case, that I do NOT want files stored via jdbc store, but rather use a cache that would spool to disk on loss of connection to the context...some of this may exist in Spring already, I havent started researching it yet...but I will add a comment or the like.
          jc

          Comment


          • #6
            You can use GemfireMessageStore for GemfireCache or you can easily implement your own MessageStore to point to the cache of your choice. Another option would be to use NoSQL datastore. We support Redis and Mongo

            Comment

            Working...
            X