|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Relation
|
|
This issue Relates To:
|
|
RHQ-2405
update the StatusManagerBean so that it doesn't change the logic it executes based on the set logging level
|
|
|
|
|
|
|
|
| Date of First Response: |
20/Jul/09 12:19 PM
|
| Tester: |
Jeff Weiss
|
| VCS Revision: |
4,180
|
some work has already bee done to remove application hot spots:
rev4160 - [ RHQ-2124][ RHQ-1656][ RHQ-1221] - removed hot spots and various other points of contention by shortening transaction times or using indexes as available for: a) uninventory work, b) cloud manager job, c) check for suspect agent job, d) dynagroup recalculation job, e) alerts cache in-band agent and server status bit setting, f) isAgentBackfilled checking
my concern is that applying changes to many template, will trickle down to hundreds if not thousands of alert definitions, taxing the agent table a lot to set the status bit. so, StatusManagerBean should be rewritten to only set status if it's absolutely necessary, and to use a simple true/false bit semantic instead of the more complicated bit mask. as an optional way to aide in remote debugging, the classic bitmask strategy should be kept if running in debug mode so that it's easier to determine whether the backend alert cache consistent protocols are working as intended.
|
|
Description
|
some work has already bee done to remove application hot spots:
rev4160 - [ RHQ-2124][ RHQ-1656][ RHQ-1221] - removed hot spots and various other points of contention by shortening transaction times or using indexes as available for: a) uninventory work, b) cloud manager job, c) check for suspect agent job, d) dynagroup recalculation job, e) alerts cache in-band agent and server status bit setting, f) isAgentBackfilled checking
my concern is that applying changes to many template, will trickle down to hundreds if not thousands of alert definitions, taxing the agent table a lot to set the status bit. so, StatusManagerBean should be rewritten to only set status if it's absolutely necessary, and to use a simple true/false bit semantic instead of the more complicated bit mask. as an optional way to aide in remote debugging, the classic bitmask strategy should be kept if running in debug mode so that it's easier to determine whether the backend alert cache consistent protocols are working as intended. |
Show » |
|
Improvement
Accepted
to test:
* update some alert definition, wait up to 30 seconds, make sure you see "reload caches info messages" and that no exceptions are thrown in the server log
* update some alert tempate, wait up to 30 seconds, make sure you see "reload caches info messages" and that no exceptions are thrown in the server log
* manually calculate some measurement baseline, wait up to 30 seconds, make sure you see "reload caches info messages" and that no exceptions are thrown in the server log
* assuming templates are setup, commit some new resources, wait up to 30 seconds, make sure you see "reload caches info messages" and that no exceptions are thrown in the server log
* let the hourly baseline job complete. assuming that even 1 baseline was calculated, make sure you see "reload caches info messages" and that no exceptions are thrown in the server log