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? |
5 answers
![]()
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 |
![]()
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. |
![]()
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 Not sure the first technique fits very well. |
![]()
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.
|
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.