Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1168941

Summary:	Disable RuleNameService to avoid BZ-1106469
Product:	[Retired] JBoss BRMS Platform 6	Reporter:	Alessandro Lazarotti <alazarot>
Component:	Business Central	Assignee:	manstis
Status:	CLOSED DUPLICATE	QA Contact:	Jiri Locker <jlocker>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.0.3	CC:	manstis, rrajasek, rzhang
Target Milestone:	ER4
Target Release:	6.1.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1168945 1175914 (view as bug list)		Environment:
Last Closed:	2015-01-20 11:02:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1168945, 1175914

Description Alessandro Lazarotti 2014-11-28 13:39:40 UTC

As described by Bug 1106469 the project authoring is getting significantly slower with increasing number of packages and rules. The root cause is how the parent rule are discovered by RuleNameServiceImpl, used by Guided Editors to allow "extends" feature.

A definitive fix is targeted to 6.1 release. It involves too many changes in 6.0.x so a backport can not be done.

This ticket is to offer a workaround to users. If they have many assets and are not using Rule Extends in Guided Editors, the RuleNameService could be disabled to improve performance. This behaviour should be configurable.

Version-Release number of selected component (if applicable):
6.0.3

How reproducible:
See Bug 1106469

Steps to Reproduce:
See Bug 1106469

Comment 5 Jiri Locker 2014-12-15 16:07:14 UTC

After applying the workaround provided by Michael to 6.0.3.GA, I was able to cut down package load time from more than 20s to some 5s for 1000 rules.

Comment 12 Jiri Locker 2015-01-20 11:02:34 UTC

This was originally targeted for a 6.0.x roll-up, which was later tracked by bz 1175914. This workaround is not needed in 6.1.0.

*** This bug has been marked as a duplicate of bug 1175914 ***