Bug 912525 - need to add concurrency limit to configuration updates from agent
need to add concurrency limit to configuration updates from agent
Status: ON_QA
Product: RHQ Project
Classification: Other
Component: Communications Subsystem (Show other bugs)
Unspecified Unspecified
high Severity high (vote)
: ---
: ---
Assigned To: John Mazzitelli
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2013-02-18 16:36 EST by John Mazzitelli
Modified: 2013-02-19 15:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Mazzitelli 2013-02-18 16:36:45 EST
Configuration updates from the agent can be expensive, and when you have lots of agents, it ends up clobbering the server and DB. We should add a new concurrency limit to:

org.rhq.core.clientapi.server.configuration.ConfigurationServerService.persistUpdatedResourceConfiguration(int, Configuration)
Comment 1 Heiko W. Rupp 2013-02-19 02:32:39 EST
We may in the long run try to "unwind" the whole configuration structure on disk, as the recursive structure does a lot of joins on the property table. 
Also the endless nesting is a pita in so many places, so that we may want to limit the possible depth (and thus also the number of joins on the table itself).

( the next may not directly apply to our case, the article itself is a good reading anyway )
From http://www.jans-sajt.se/contents/ora2/plsql/Oracle_SQL_SELECT.htm

"queries on queries ("cascades") are often imperformant when not tuned for speed. Like view-on-view cascades, only the deepest query/view can use indexes, while the pendend super-selects always are full table scans (of the result set) inside the database cache! If You cannot escape this, than make sure that Your deepest result sets are as small as possible, and put all the WHERE filters there!"
Comment 2 John Mazzitelli 2013-02-19 11:53:13 EST
adding a new concurrency limit requires changes to the docs:


and rhq-server.properties - something like:

Comment 3 John Mazzitelli 2013-02-19 15:14:30 EST
master git commit: 3005a262a20961e6c8583e02953d9af1501d8c68

this is a code change - not much to do to test. If you want to see this, turn on debug messages in server. In rhq-server.properties, set "rhq.server.concurrency-limit.configuration-update" to something low, like 1. Then import alot of resources at the same time (those resources must have <resource-configuration> associated with them). If you hit concurrency limits, you'll see this log message:

"Command not permitted - server reached its limit of concurrent invocations ..."

Note You need to log in before you can comment on or make changes to this bug.