Bug 1296588 - Opening a repository takes a long time in BRMS 6.2
Opening a repository takes a long time in BRMS 6.2
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
high Severity high
: DR1
: 6.3.0
Assigned To: manstis
Depends On:
Blocks: 1296498
  Show dependency treegraph
Reported: 2016-01-07 10:42 EST by Alessandro Lazarotti
Modified: 2016-02-17 08:50 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1296498
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 Alessandro Lazarotti 2016-01-07 10:42:29 EST
+++ This bug was initially created as a clone of Bug #1296498 +++

Description of problem:

We have a customer who has installed a BRMS 6.2 and migrated their rules from BRMS 6.1. They have two repositories (ClaimsCycle and Authorization). ClaimsCycle repo has around 1200 rules and Authorization repo has 10 rules. When they try to switch "Authorization" repo to "ClaimsCycle" repo from business central it is taking more than 20 mins to open the ClaimsCycle repo in BRMS 6.2 while in BRMS 6.1 it was taking 1 to 2 mins.

We have followed the same steps as customer and we have reproduced the same issue.

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

BRMS 6.2.0 - EAP 6.4.5

How reproducible:

We have attached the files useful for the test and analysis:

--> Thread Dumps 6.1-6.2.zip
    - It contains the thread dumps collected by the customer for comparing between BRMS 6.1 and BRMS 6.2.
       1. Thread Dumps_6.1 -->  thread dump for BRMS 6.1
       2. Thread Dump__6.2_1st Set --> 1st set of thread dump of BRMS 6.2
       3. Thread Dump__6.2_2nd Set --> 2nd set of thread dump of BRMS 6.2
--> niogit.rar
    - It contains the repositories to clone: ClaimsCycle and Authorization
--> repository.zip
    - It contains the JARs files used by the ClaimsCycle repository

Steps to Reproduce:
1. Install EAP 6.4.5
2. Install BRMS 6.2.0
3. Access to business central and login
4. Go to Authoring -> Administration
5. Repositories -> Clone repository
    Repository Name: ClaimCycle
    Organizational Unit: example
    Git URL: file://<path_to_ClaimsCycle.git_in_.niogit>
6. Repositories -> Clone repository
    Repository Name: Authorization
    Organizational Unit: example
    Git URL: file://<path_to_Authorization.git_in_.niogit>
7. Go to Authoring -> Artifact repository
    Upload the following files from repository.rar:
8. Go to Authoring -> Project Authoring
9. Authorization repository is selected in the Project Explorer
10. Switch to ClaimCyle repository in the Project Explorer
11. Go to com/daman/brms which contains all the rules (around 1200) -> it takes a lot of time in BRMS 6.2

Actual results:

When we switch "Authorization" repo to "ClaimsCycle" repo from business central it is taking more than 20 mins to open the ClaimsCycle repo in BRMS 6.2.

Expected results:

It should be opened from 1 to 2 mins aprox as in BRMS 6.1.

--- Additional comment from Oscar Molina on 2016-01-07 06:45 EST ---

--- Additional comment from Oscar Molina on 2016-01-07 06:48 EST ---

--- Additional comment from JBoss Product and Program Management on 2016-01-07 06:50:19 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 2016-01-07 07:16:49 EST ---

Analysis provided by mweiler@redhat.com: 


I can confirm that removing the change you mentioned brings down the loading time from > 7 minutes to ~ 5 seconds!

[mweiler@martin kie-wb-common-project-explorer-backend]$ git diff
diff --git a/kie-wb-common-screens/kie-wb-common-project-explorer/kie-wb-common-project-explorer-backend/src/main/java/org/kie/workbench/common/screens/explorer/backend/server/ExplorerServiceHelper.java b/kie-wb-common-screens/kie-wb-common-project-explorer/kie-wb-common-project-explorer-backend/src/main/java/org/kie/workbench/common/screens/explorer/backend/server/ExplorerServiceHelper.java
index 0e35386..f5e902e 100644
--- a/kie-wb-common-screens/kie-wb-common-project-explorer/kie-wb-common-project-explorer-backend/src/main/java/org/kie/workbench/common/screens/explorer/backend/server/ExplorerServiceHelper.java
+++ b/kie-wb-common-screens/kie-wb-common-project-explorer/kie-wb-common-project-explorer-backend/src/main/java/org/kie/workbench/common/screens/explorer/backend/server/ExplorerServiceHelper.java
@@ -247,7 +247,7 @@ public class ExplorerServiceHelper {


-                                                              lockedBy, metadataService.getMetadata( path ).getTags() );
+                                                              lockedBy, new ArrayList<String>(  ) ); //, metadataService.getOtherMetadata( path ).getTags()
                 folderItems.add( folderItem );

--- Additional comment from Kris Verlaenen on 2016-01-07 10:04:55 EST ---

From mweiler (email):

I created PRs for both aspects, getting the tags only instead of the full metadata, and for retrieving them only if the tags option is present:


Kindly review and comment. I think this really is a big issue, as it will affect all users with larger repositories, so we should aim to get it into 6.2.1.
Comment 5 Martin Weiler 2016-01-15 11:54:31 EST
With the commits from this BZ, the performance in the Authoring perspective is similar to what it was in 6.1, if the "Tag filtering" option is disabled (the default setting).

The commits also contain some performance improvements when "Tag filtering" is enabled. However, this feature still has a considerable impact on performance.

To track further performance improvements with "Tag filtering" feature enabled, a new BZ has been created:
Comment 7 jsoltes 2016-02-17 08:50:18 EST
Tested on bpm-suite 6.3.0. Opens under 1 minute.

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