I was stuck on how to help you for a while, and part of the problem is
that there are a couple different questions (from what I understand)
built into your post:

1. How do I make a scheduled task run at different times after it is
first started?

This is a pretty common thing to do, as the nightly LDAP sync and the
data-warehouse snapshot tasks want to accomplish the same thing. Both
of those services re-implement
AbstractAutoScheduledTask.getFixedDelay(). That seems like a good fit
for your service as well. You would return a small number the first
time it's called and then the larger number every time after that. In
fact, if you take that approach (and never call super.getFixedDelay())
then you shouldn't need to have the delay configuration property at all.
You can remove it to avoid any confusion from your users.

2. How can a service change it's configuration properties on the fly?

This question probably isn't as useful to you if you take the approach
above, but the answer is: There isn't a public way for a service to
update it's configuration properties (with the exception of making a
REST call back to the same service and use the
IServerConfigurationRestService remotely). Calling
updateConfigurationProperties() on your own service just tricks the
service into thinking that somebody changed the configuration property
without actually changing it (which is why the web UI didn't update the
new value)

Let me know if the removal of the config property and implementing
getFixedDelay works for you.


Matt Lavin
Jazz Server Team


jnason wrote:

We use AbstractAutoScheduledTask for some of our periodic back-ground
tasks. There is one in particular that we want to run shortly after
start-up, but then much less frequently thereafter. Currently, after
the task runs the first time I use updateConfigurationProperties to
update the sync delay property. It works fine - except the change is
not reflected in the "Current Value" of this property in
the Jazz Administrative UI. Users may want to alter this value so it
is potentially misleading to them.
see: https://jazz.net/wiki/bin/view/Main/ConfigurationStory for more
information on Configuration Properties.

I started looking at
IServerConfigurationRestService::postConfigurationUpdates and the
underlying methods that it uses but it is all "discouraged
access".
Does anyone have recommendations for how server-side code should
modify these properties so that they are accurately represented in
the Administration web UI?

Not sure the first technique fits very well.

I'm in the consumer side of this situation (providing code that will be called by this scheduled task).

We'd want to have it called quite often to support testing, but less often in production.

But, the user/customer behavior and needs are unpredictable, so we'd like them to be able to define the repeat interval via the properties.

Is there a way to call the processing once at server start that is outside the scheduled task route and then let the normal schedule take off from there? (run at 0 and then every 300 seconds, or 1800 seconds, or what ever the user defines as the config value).

Couldn't a plugin's startup logic force this call once or manually invoke the scheduled task/task logic?

You could do a combination of the two approachs. If you wanted the task
to execute quickly on startup, then you could have getFixedDelay()
return a small number the first time it's asked, and then return
super.getFixedDelay() every time after that. You'd need to keep the
config value, but you wouldn't need to update it programatically.

Having code execute in the plugin's startup logic is not a good idea.
There are cases where your plugin might start but running scheduled
tasks is not appropriate. Also, you would have a hard time getting the
right context to run the task with all of it's service dependencies.

Matt Lavin
Jazz Server Team


patmc wrote:

Not sure the first technique fits very well.

I'm in the consumer side of this situation (providing code that will
be called by this scheduled task).

We'd want to have it called quite often to support testing, but less
often in production.

But, the user/customer behavior and needs are unpredictable, so we'd
like them to be able to define the repeat interval via the
properties.

Is there a way to call the processing once at server start that is
outside the scheduled task route and then let the normal schedule
take off from there? (run at 0 and then every 300 seconds, or 1800
seconds, or what ever the user defines as the config value).

Couldn't a plugin's startup logic force this call once or manually
invoke the scheduled task/task logic?

I have aquestion here, will the value that is updated on fly will remain even after the server is started nexttime. I coul dsee only the default value is set back. How to retain the previous value which is entered.