Announcement Announcement Module
Collapse
No announcement yet.
Switching a poller off Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Switching a poller off

    Is there anyway to switch a poller off?

    We are trying to be consistent in two areas with our bus implementation. Keeping all thread control with in the spring configuration context, and not introduce any dependencies in our implementation classes on the Spring Jars outside of the bootstrap class.

    The scenario:

    after initialization poll a webservice until it becomes available
    enable client requests on a gateway ( done by publishing the successful result to a pub subscribe channels. At this point polling should stop.

  • #2
    That is an interesting use-case. The first thing that comes to mind is that you might want to implement a custom Trigger.

    Are you using 2.0 Milestones or 1.0.x?

    Comment


    • #3
      1.0.

      The use case has to do with disadvantaged networks. Imagine mobile platforms with wireless connections that are constrained in band widths. There is a need to minimize requests on the wire so its benificial to have clients have the ability to suppress requests unless and until a service is available. For the same reason a heartbeat poller is not acceptable. Basically once a service is detected, it is assumed available until a request fails. Since the platforms are moving, and wireless, its possible that an obstruction blocks availability for significant periods of time.

      Jeff
      Last edited by jeff_gaer; Mar 2nd, 2010, 10:45 AM.

      Comment


      • #4
        I will be interested to see the turning off feature as well. Although my thinking is inbound channel adapters should stop "listening" after business hours or weekends

        Comment


        • #5
          The "business hours" and "weekend" cases should be achievable with cron expressions (using <cron-trigger/>).

          Comment


          • #6
            looking at the schema quickly, it has to be part of a chain? or can i define it inside the <inbound-channel-xxxx

            My apologies to the original poster for deviating

            Comment


            • #7
              Never mind. I see the poller can be defined inside inbound

              Comment


              • #8
                The trigger can stop entirely by returning null, although the problem is then that it cannot be turned on anymore.

                Related use case that I saw was this:
                poll first from directory A, when that is empty start polling from directory B

                This was impossible to implement with a custom Trigger (I did it with a custom FileListFilter instead).

                Can you share more details on the use case?

                Comment


                • #9
                  use case

                  Wireless network connections, some platforms may be physically moving so connectivity is intermittent. A data collection client needs to connect to a large number of services and collect data at rates that may tax its bandwidth, so it cant do the polling. It needs to be notified of services that are available ( a registration process). Available services connect to the client and then the client makes calls to the service. Many of the services are web services that may or may not be available at any point in time so one function of the spring integration buss is poll a set of potential providers and notify the client when one is available .


                  The web service may either come up before the spring integration bus, after the integration buss, or may not be available at all. The buss polls the web service for availability at startup when/if it detects a service at that endpoint, it connects to the client, polling can discontinue at this point because it is determined that a service is available. While subsequent requests may fail, client can determine/control retry frequency, or close connection and request polling start back up in which case it will be notified again when a service is available.

                  The web service is connected via a spring-ws outbound gateway. The client uses a proprietary protocol over a raw socket. The buss connects to the socket at a known address, does some handshaking where it announces its capabilities and then does blocking reads via a 0 delay poller to receive requests.

                  Current implementation uses a polling thread in an adapter class, but we would like to eliminate any internal threads and completely rely on the integration buss for thread management.

                  Comment


                  • #10
                    Would it make sense for Spring to provide capability for a listener similar to Quartz's TriggerListener that would give you the flexibility to veto an execution based on a runtime condition?

                    Comment


                    • #11
                      Originally posted by jglynn View Post
                      Would it make sense for Spring to provide capability for a listener similar to Quartz's TriggerListener that would give you the flexibility to veto an execution based on a runtime condition?
                      That's one way to solve it, there are other ways too. I think it would be good to make an issue for this if that wasn't done already.

                      Comment


                      • #12
                        Thinking about this some more, I realized that you probably don't want to push this logic into the trigger. I assume that whenever the poller is on, the Trigger can have the same configuration. What is actually desired is the ability to turn the poller on and off... and back on again. Is that correct?

                        If so, then this is really just a matter of calling start/stop on the PollingConsumer endpoint. That is an implementation of Spring's Lifecycle interface. Also, very soon those methods will be exposed as JMX operations.

                        Comment


                        • #13
                          Originally posted by Mark Fisher View Post
                          What is actually desired is the ability to turn the poller on and off... and back on again. Is that correct?

                          If so, then this is really just a matter of calling start/stop on the PollingConsumer endpoint.
                          There is a another hairy issue with that. We found that starting the context as a whole should be a separate concern from preventing polling from one directory. If you have the requirement to defer the start of one poller there is no clean way to do it that I found.

                          Comment


                          • #14
                            The 'auto-startup' property of the endpoint doesn't solve that problem?

                            Comment


                            • #15
                              Hi!

                              I have a similar case. Our application uses three external systems: a database and two web services. I would like to implement the option of checking the state of these external systems, and if any of them is unavailable, then switching off the poller.

                              I have already implemented 3 so-called "watchdogs": they check the availability of each external system and can notify the user if any of systems is off. Now I would like to improve the poller: it should check the statuses before each poll and if something wrong it should skip the round.

                              How can it be done easily, assuming I would like to leave the configuration of "trigger" and "transactional" elements as they are?

                              Comment

                              Working...
                              X