+++ This bug was initially created as a clone of Bug #1168941 +++

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

— Additional comment from JBoss Product and Program Management on 2014-11-28 08:40:17 EST —

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

— Additional comment from on 2014-11-28 08:42:53 EST —

kie-wb-common
-------------
(6.0.x) http://github.com/droolsjbpm/kie-wb-common/commit/8f883d766

drools-wb
---------
(6.0.x) http://github.com/droolsjbpm/drools-wb/commit/a410a6833

This change requires the following JARs be replaced in WEB-INF/lib:-

1) org.kie.workbench.services:kie-wb-common-services-api
2) org.kie.workbench.services:kie-wb-common-services-backend

This will allow the RuleNameService to be disabled by following these steps:

1) Deploy BRMS/BPMS
2) Clone the "System" repository into a temporary folder:

> cd ~/
> mkdir ./temp
> cd ./temp
> git clone ssh://<admin-user>@localhost:8001/system
> cd ./system

3) Change file ~/temp/system/settings.global to include this:

<entry>
<string>build.enable-rule-name-service</string>
<item>
<name>build.enable-rule-name-service</name>
<value class="string">false</value>
</item>
</entry>

4) Add and commit the change

> git add .
> git commit -m "Disable RuleNameService"
> git push origin master

5) Restart the application

6) The log should show the following on restart:

> INFO [org.guvnor.common.services.backend.config.ApplicationPreferencesLoader] (MSC service thread 1-5) Setting preference 'build.enable-rule-name-service' to 'false'.

7) When the "Authoring Perspective" is visited the log should further show:

> INFO [org.kie.workbench.common.services.backend.rulename.RuleNameServiceImpl] (http-/127.0.0.1:8080-1) RuleNameService is not enabled. Parent Rule Names will not be available in the Workbench.

When a full roll-up patch is released and a new WAR compiled the Guided Rule Editor, Guided Decision Table Editor and Guided Template Editor will not include a drop-down to select "parent" rules from which one can extend another.

If just the JARs are replaced the service can be disabled but the UI will still show the dropdowns however they will be empty.

— Additional comment from JBoss Product and Program Management on 2014-11-28 08:50:17 EST —

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

— Additional comment from JBoss Product and Program Management on 2014-12-09 10:30:18 EST —

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

— Additional comment from Jiri Locker on 2014-12-15 11:07:14 EST —

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.

— Additional comment from Jiri Locker on 2014-12-15 11:13:18 EST —

Ryan, I believe this bug is targeted for the next 6.0 rollup judging by brms-rollup-2-6.0.x flag raised by Alessandro. The jboss-brms-6.1.0 flag was automatically raised by pm-jboss bot and shouldn't be considered. Subsequently, target release and milestone were set to 6.1.0.ER3 by mistake.

Please confirm and clear target release and milestone and move back to MODIFIED if you agree.

— Additional comment from Ryan Zhang on 2014-12-17 21:58:04 EST —

(In reply to Jiri Locker from comment #6)
> Ryan, I believe this bug is targeted for the next 6.0 rollup judging by
> brms-rollup-2-6.0.x flag raised by Alessandro. The jboss-brms-6.1.0 flag was
> automatically raised by pm-jboss bot and shouldn't be considered.
> Subsequently, target release and milestone were set to 6.1.0.ER3 by mistake.
>
> Please confirm and clear target release and milestone and move back to
> MODIFIED if you agree.

Yes, Thanks Jiri pointing it out.
This is for rollup2, not for jboss-bpms-6.1.

— Additional comment from JBoss Product and Program Management on 2014-12-17 22:00:20 EST —

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.