History | Log In     View a printable version of the current page.  

jira.rhq-project.org has been archived and is now in read-only mode.

All issues have been moved to bugzilla.redhat.com. All new issues or updates to existing issues should be made through bugzilla.
Specific old RHQ issues can be found using a query of this form: https://bugzilla.redhat.com/show_bug.cgi?id=RHQ-1999.
New bugs can be raised here. Accounts at bugzilla.redhat.com have been created for existing RHQ users.
Open bugs raised in the last week can be found here.
Issue Details (XML | Word | Printable)

Key: RHQ-792
Type: Improvement Improvement
Status: Accepted Accepted
Priority: Critical Critical
Assignee: Joseph Marques
Reporter: Joseph Marques
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
RHQ Project

asynchronous updating of metric tempates / schedules

Created: 06/Sep/08 01:12 AM   Updated: 18/Sep/09 03:17 PM
Component/s: Domain Entities, FX - Measurement, Core Server
Fix Version/s: 1.1

Time Tracking:
Not Specified

Issue Links:
Relation
 

Date of First Response: 19/Sep/08 01:04 PM
Tester: Corey Welton


 Description  « Hide
today, an update to a metric schedule requires that the corresponding agent be online. while this doesn't seem that restrictive, it becomes problematic at large scales. in particular, updating of a metric template (which updates all schedules for all resources of the corresponding type) require that all agents for all resources be online.

improvement: make schedule updates asynchronous. using the UI should return immediately, whether or not the agent is online. if the agent is online, it should get the update (relatively) immediately. if the agent if offline, there should be logic that the agent checks where the server-side schedules need to be updated.

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Joseph Marques - 06/Sep/08 06:18 PM
rev1373 - test to make sure the corresponding AgentClient is up, before interacting with it (use 2000ms timeout);
on the crazy off-chance that the AgentClient is available but sending the report fails, catch Throwable to make sure the caller's request will continue to completion;
update mtime's of resources whose MeasurementSchedules are being changed (directly on the resource, or indirectly through the metric template);
while i was at it, improve the performance of the end-to-end flow for metric tempalte updates by batch all ResourceMeasurementSchedulesRequest's for a single agent into a single remote method call and, more importantly, single check against the availability of the corresponding AgentClient;

Joseph Marques - 06/Sep/08 06:52 PM
test 1 - single resource, update schedule, agent online

1) go to some resource in inventory whose agent is up
2) navigate to monitor > configuration subtab
3) change some collection interval to something odd like 42s
4) go to that agent prompt and execute "inventory -x -e inv.dat"
5) then in a sep terminal execute "cat inv.dat | grep 42000 -c" and make sure the count is precisely 1

test 2 - single resource, disable schedule, agent online

1) go to some resource in inventory whose agent is up
2) navigate to monitor > configuration subtab
3) disable the collection interval that you previously marked with 42s
4) go to that agent prompt and execute "inventory -x -e inv.dat"
5) then in a sep terminal execute "cat inv.dat | grep 42000 -B 1" to make sure this schedule has been disabled agent-side

Joseph Marques - 06/Sep/08 06:52 PM - edited
test 3 - single resource, update schedule, agent offline

1) repeat steps 1-3 from test 1...but change the time to, say, 31 seconds
2) turn the agent back on and wait 30-60 seconds for the first inventory report to be sent (you can confirm when this happens if you tail the server log)
3) repeat steps 4 & 5 from test 1

test 4 - single resource, disable schedule, agent offline

1) repeat steps 1-3 from test 2...but disable the one you just set to 31 seconds
2) turn the agent back on and wait 30-60 seconds for the first inventory report to be sent (you can confirm when this happens if you tail the server log)
3) repeat steps 4 & 5 from test 2

Joseph Marques - 06/Sep/08 06:52 PM - edited
test 5 - multi-resource, update schedule, agent online

1) go to admin > monitoring defaults > choose some resource type (and make sure you count the number of resources of that type in your inventory, we'll call this value X)
2) change some collection interval for a single schedule to something odd like 53s
3) go to that agent prompt and execute "inventory -x -e inv.dat"
4) then in a sep terminal execute "cat inv.dat | grep 53000 -c" and make sure the count is precisely X

test 6 - multi-resource, disable schedule, agent online

1) go to admin > monitoring defaults > choose some resource type (and make sure you count the number of resources of that type in your inventory, we'll call this value X)
2) disable the collection interval that you previously marked with 53s
3) go to that agent prompt and execute "inventory -x -e inv.dat"
4) then in a sep terminal execute "cat inv.dat | grep 53000 -B 1" and make sure that all X entries are disabled now

Joseph Marques - 06/Sep/08 06:58 PM
test 7 - multi-resource, update schedule, agent offline

1) repeat steps 1 & 2 from test 5, but change the time to, say, 67 seconds
2) turn the agent back on and wait 30-60 seconds for the first inventory report to be sent (you can confirm when this happens if you tail the server log)
3) repeat steps 3 & 4 from test 5

test 8 - multi-resource, disable schedule, agent offline

1) repeat steps 1 & 2 from test 6, but disable the one you just set to 67 seconds
2) turn the agent back on and wait 30-60 seconds for the first inventory report to be sent (you can confirm when this happens if you tail the server log)
3) repeat steps 3 & 4 from test 6

Joseph Marques - 06/Sep/08 07:33 PM
rev1375 - scale back logging on the sever-side for measurement schedule and metric template updates;

Corey Welton - 19/Sep/08 01:04 PM
QA Verified.