This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Problems while trying to modify polling rate on runtimePage Title Module

When i debug this solution, I can see that the adapter has this new trigger attached to it, however the polling rate remains unchanged (every 5 secs). I tried also to stop() and start() the adapter, with similar luck.

Under the covers we are simply creating a PeriodicTrigger instance (it is defined in the Spring Framework core), and it accepts the "interval" as a constructor argument. Therefore it cannot be changed at runtime. However, you can define your own implementation of the Trigger interface, even using the PeriodicTrigger as a starting point. Then, you could add a setter for the interval (or even embed your throttling logic within the trigger itself if possible). Then, the interval can be changed between polls. It will be used with each call to nextExecutionTime (to schedule the next poll), so that should have the desired effect. To use your poller, remove the 'fixed-rate' attribute from your poller element and add a 'trigger' attribute referencing your instance instead. In other words, you would provide a Trigger that has dynamic capabilities itself rather than changing the Trigger reference at runtime.

Going back to you original post, you CAN modify it if you implement your own Trigger and set it on the poller via 'trigger' attribute. You can than expose properties on the this custom Trigger implementation that allow you to change how the next execution time is calculated.

Trigger is a very simple strategy (as yo can see from above) that defines only one method which is invoked by scheduler after each successful invocation of the task. What happens and how it happens in the Trigger.nextExecutionTime(..) is entirely up to the implementation.