Mule
  1. Mule
  2. MULE-1241

More flexible polling/scheduling support for receivers

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix or Usage Issue
    • Affects Version/s: 1.3.2
    • Fix Version/s: None
    • Component/s: Core: API
    • Labels:
    • User impact:
      Low
    • Similar Issues:
      MULE-7044Make poll schedulers part of the same namespace
      MULE-3More flexible configuration mechanism
      MULE-2236Consider more flexible root element
      MULE-1394Refactor UMOEntryPoint for concurrency and more flexible implementation
      MULE-860XFireConnector depends on Java 5
      MULE-1242Non-materializing streaming receiver for TCP
      MULE-6592Simplify migration to 3.4 for custom http receivers
      MULE-4975HttpMessageReceiver: Available receivers shouldn't be logged on warn level
      MULE-2521Notification when polling transport's message receiver is 'finished'
      MULE-424Only Transacted Jms receiver when using transactions

      Description

      Original thread: http://www.nabble.com/Scheduling-API-design-tf2731079.html

      As first step implement a pluggable strategy for PollingMessageReceiver, as outlined in http://www.nabble.com/Scheduling-API-design-tf2731079.html.

        Issue Links

          Activity

          Hide
          Ben Hood added a comment -

          Hi Holger, no worries, I can see where you're coming from. As an outsider, its difficult to judge the actual status quo of the Mule code base and what is the cutting edge, so therefore I just went for a solution that works now with the current code. At our company, we developed a solution that solves the cron problem on the UMO level using a buffering outbound router as a countdown latch, but I wanted to solve the problem more wholistically (but sadly didn't . Is there anything one can look at to maybe help out with solving this problem, or are there simply too many things in flux at the moment?

          Having said that, I didn't know that endpoints can now receive(), so I might look into that.......

          Show
          Ben Hood added a comment - Hi Holger, no worries, I can see where you're coming from. As an outsider, its difficult to judge the actual status quo of the Mule code base and what is the cutting edge, so therefore I just went for a solution that works now with the current code. At our company, we developed a solution that solves the cron problem on the UMO level using a buffering outbound router as a countdown latch, but I wanted to solve the problem more wholistically (but sadly didn't . Is there anything one can look at to maybe help out with solving this problem, or are there simply too many things in flux at the moment? Having said that, I didn't know that endpoints can now receive(), so I might look into that.......
          Hide
          Dirk Olmes added a comment -

          Holger, does this still apply after all the changes that were made to the scheduling/polling?

          Show
          Dirk Olmes added a comment - Holger, does this still apply after all the changes that were made to the scheduling/polling?
          Hide
          Holger Hoffstaette added a comment -

          Yes, this is about something different (though related). By default a PollingMessageReceiver either polls periodically or not; the idea is to make this behaviour pluggable to allow polling e.g. once-a-day. See the comment above about triggering this via the quartz "transport".
          Essentially this is one of those "would be nice" features that are a lot more difficult than they seem

          Show
          Holger Hoffstaette added a comment - Yes, this is about something different (though related). By default a PollingMessageReceiver either polls periodically or not; the idea is to make this behaviour pluggable to allow polling e.g. once-a-day. See the comment above about triggering this via the quartz "transport". Essentially this is one of those "would be nice" features that are a lot more difficult than they seem
          Hide
          Holger Hoffstaette added a comment -

          Btw this qualifies as "new feature" and could easily be transferred into 2.x.

          Show
          Holger Hoffstaette added a comment - Btw this qualifies as "new feature" and could easily be transferred into 2.x.
          Hide
          Ross Mason added a comment -

          The quartz support in Mule 2.0 can be used to achieve the behaviours described here. http://mule.mulesource.org/display/MULE2USER/Quartz+Transport (Check out the Endpoint Polling Job). I agree with Holger's assessment about how scheduling could be integrated into Message Receivers. However, since we already have the functionality, I don't see any point progressing with this.

          Ben, thank you for you contributions here.

          Show
          Ross Mason added a comment - The quartz support in Mule 2.0 can be used to achieve the behaviours described here. http://mule.mulesource.org/display/MULE2USER/Quartz+Transport (Check out the Endpoint Polling Job). I agree with Holger's assessment about how scheduling could be integrated into Message Receivers. However, since we already have the functionality, I don't see any point progressing with this. Ben, thank you for you contributions here.

            People

            • Assignee:
              Ross Mason
              Reporter:
              Holger Hoffstaette
            • Votes:
              4 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development