Changing polling interval with jmx

[magott]

Hi,

I'm trying to use JMX to change my polling interval. I have the following poller configuration:

	<int:poller fixed-rate="60000" max-messages-per-poll="10" id="defaultPoller" default="true">
		<int:transactional transaction-manager="transactionManager" />
	</int:poller>

I created a class I'm exposing as an MBean:

public class IntegrationController{
     
    @Autowired
    private PeriodicTrigger periodicTrigger;
    
    @ManagedOperation
    public void setPollingInterval(long seconds){
        periodicTrigger.setInitialDelay(seconds*1000);
    }

The app starts OK (no problem with the autowiring) and I'm able to set the initialDelay over over jmx, but it doesn't seem to help. Is this not supposed to work? The initialDelay in PeriodicTrigger is volatile, which suggest it should be able to cope with changes?

[oleg.zhurakousky]

Well, initial delay (as the name suggests) and as you can see from 'nextExecutionTime' method is evaluated only once during the initial execution so changing it make no difference for the subsequent executions.

As fo the other issue I would sugest raising JIRA in SPR.

[magott]

Yeah, you are of course right, I didn't examine the class fully. But then again, why is it volatile? I'm guessing the setter will only be called during the context initialization, in which case the trigger should be 'protected' by the synchronization in the bean factory? Anyway, is there no way to change the trigger without restarting the app?

[Dave Syer]

As Oleg said, the trigger is only initalized once if it is a singleton bean. The trick to setting a trigger at runtime is to use a proxy wrapper to force a re-initialization. I did this in one of the CloudFoundry samples (see config file at https://github.com/SpringSource/clou...rap-config.xml). There is also a SPR issue to provide the auto-proxying out of the box with a RefreshScope (https://issues.springsource.org/browse/SPR-8075). Vote for it if you like the idea.

[oleg.zhurakousky]

That is right, but I think its still a valid point about changing PriodicTrigger's period. If you provide a custom trigger via 'ref' then you can expose that custom trigger via JMX and do whatever it is you want to do, so essentially you can copy PriodicTrigger's code, expose setter on the 'period' and accomplish what you expect, so I'd suggest to raise another SPR JIRA to expose setters foro the 'period' on the PeriodicTrigger.