Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Updating Jazz Configuration properties from the server

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?

0 votes



5 answers

Permanent link
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?

0 votes


Permanent link
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?

0 votes


Permanent link
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?

0 votes


Permanent link
Great minds think alike;-)
Using your original response as guidance, that's exactly how I've gone and modified the behavior. Basically I just needed to reverse the logic: use the long value as the default, with the short value returned programatically via the getFixedDelay override before the task is run the first time.
Now the task runs at start-up and the "normal" delay is represented accurately in the UI.

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?

0 votes


Permanent link
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.

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,937

Question asked: Sep 05 '08, 9:05 a.m.

Question was seen: 7,619 times

Last updated: Sep 05 '08, 9:05 a.m.

Confirmation Cancel Confirm