This is related to Case 01038335. A customer has a situation where a monitored server has thousands of EJBs deployed. This creates a situation with a huge child cardinality for a single parent, which is a worst case scenario in various ways, but is certainly bad for inventory merge and can cause server OOMs. Some investigation should be done to see if we can improve performance for this use case. Note that the same high cardinality use case may cause issues in other ways, this BZ is limited only to this use case, relevant to the customer case.
Moving to POST to let it run in master a bit, just to make sure I'm not missing something here... master commit bdeeef8ab36aed0d7d1f38dcb9d19c8cc8150ca0 Author: Jay Shaughnessy <jshaughn> Date: Fri Aug 22 15:44:09 2014 -0400 In our continuing search for new planets, new civilizations, er, strike that, our need for better performance, this change ensures we don't pull child sets unnecessarily during inventory merge. This is very important in the given use case, but should benefit all inventory merge to some degree.
*** Bug 954010 has been marked as a duplicate of this bug. ***
Merged into release/jon3.3.x commit 663661c7ca53ef9b0ca4218262c280d2fef4e252 Author: Jay Shaughnessy <jshaughn> Date: Fri Aug 22 15:44:09 2014 -0400 (cherry picked from commit bdeeef8ab36aed0d7d1f38dcb9d19c8cc8150ca0) Signed-off-by: Thomas Segismont <tsegismo>
Moving to ON_QA as available for test with the following brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=381194