Yes, you can use a cron trigger to run, say every n seconds between noon and 2pm.
However, let me clarify my earlier points about orderly shutdown of a polled message source.
When you stop() a SourcePollingChannelAdapter (such as a file:inbound-channel-adapter), we cancel the scheduled task (ScheduledFuture) with "mayInterruptIfRunning" true. This means that any interruptible code in the message source (including custom filters) will be interrupted. This doesn't mean any messages will be lost (as long as you use an external task executor), because they havent't been dispatched yet, but it could cause issues, depending on the message source.
To avoid this, you can use your own TaskScheduler (e.g. ThreadPoolTaskScheduler) with 'waitForTasksToCompleteOnShutdown' set to true.
Calling shutdown on this scheduler will also cancel the ScheduledFuture, but it won't interrupt the thread if it's running.
You can then wait for its 'scheduledExecutor' to stop (test its isShutdown() property).
Finally, you can then safely call the adapter's stop() method because there is no longer a ScheduledFuture to cancel.
To clarify further - there are two Task* entities involved. The TaskScheduler schedules a poll (based on the trigger) and a TaskExecutor which sends any messages resulting from the poll.
By default, we use an automatically created TaskScheduler (bean name "taskScheduler") and a SyncTaskExecutor (which means the message send occurs on the scheduler's thread).
Although it's not supported by the namespace, you can call setTaskScheduler() on the channel adapter to use a custom scheduler instead of the default (or simply replace the default "taskScheduler" bean - if you don't mind stopping all scheduled tasks). If you inject your own scheduler, it's best to set auto-startup to false and start() it manually after injecting the scheduler.
You can also inject your own task executor on the poller (that is supported by the namespace). This means the scheduler will hand off to that executor meaning in-flight messages won't be affected, and stopping the scheduler won't have to wait for all in-flight messages to complete processing.
I hope that makes things clearer.
The 2.2. work was specifically to provide an orderly shutdown of the entire context but, after writing this post, I can see that it would be nice to provide a built-in option to stop individual adapters in an orderly fashion. Please feel free to open a JIRA.
Gary P. Russell
Spring Integration Team
SpringSource, a division of VMware