Hide Forgot
+++ 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: brms_mednext_drop_down-1.jar data-package-1.0.jar ojdbc-14.jar ons-1.0.jar resource-3.1.2.jar transaction-3.0.jar 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: <snip> 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 { path.getFileName(), FolderItemType.FILE, false, - 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: https://github.com/droolsjbpm/guvnor/pull/212 https://github.com/droolsjbpm/kie-wb-common/pull/191 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.
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: https://bugzilla.redhat.com/show_bug.cgi?id=1299006
Tested on bpm-suite 6.3.0. Opens under 1 minute.