| Key: |
RHQ-1122
|
| Type: |
Improvement
|
| Status: |
Open
|
| Priority: |
Critical
|
| Assignee: |
Unassigned
|
| Reporter: |
John Mazzitelli
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Dependency
|
|
This issue Depends On:
|
|
|
RHQ-1064 default event purge time should be less than a month
|
|
|
|
|
|
Relation
|
|
This issue Relates To:
|
|
|
RHQ-114
large numbers of agent requests (e.g. content reports) seem to blow up hibernate
|
|
|
|
|
|
|
|
| Date of First Response: |
19/Nov/08 11:24 AM
|
|
We need a way to throttle the amount of events we store in the database.
If, for example, a JbossAS server resource is capturing events from its log4j at the WARN level, and something goes horribly wrong in that managed resource that causes WARN messages to emit infinitly, we could blow up our server by asking it to insert an abnormal amount of events. (see linked issue as an example of this happening).
We should have a threshold (perhaps configurable on a per resource basis, or on a whole event-subsystem global basis) that says, "if we get more than X events in an event report, only insert X-N events" or maybe time based in the plugin container like "if we get X events in Y seconds, only report back X-N events".
Perhaps we do some kind of filtering - if we get similar events in X seconds, only send up 1 of them.
In short, we need a throttling mechanism to avoid inserting too many events in the database.
|
|
Description
|
We need a way to throttle the amount of events we store in the database.
If, for example, a JbossAS server resource is capturing events from its log4j at the WARN level, and something goes horribly wrong in that managed resource that causes WARN messages to emit infinitly, we could blow up our server by asking it to insert an abnormal amount of events. (see linked issue as an example of this happening).
We should have a threshold (perhaps configurable on a per resource basis, or on a whole event-subsystem global basis) that says, "if we get more than X events in an event report, only insert X-N events" or maybe time based in the plugin container like "if we get X events in Y seconds, only report back X-N events".
Perhaps we do some kind of filtering - if we get similar events in X seconds, only send up 1 of them.
In short, we need a throttling mechanism to avoid inserting too many events in the database.
|
Show » |
|
I suggest for one we limit the number of events in the database to 7 days worth. See RHQ-1064