Status: Closed (View Workflow)
Affects Version/s: 6.0.0, 6.1.0, 6.0.1, 6.2.0, 6.0.2, 6.1.1, 6.0.3, 6.1.2, 6.0.4, 6.1.3, 6.3.0, 6.0.5, 6.1.4, 6.2.1, 5.16.6, 6.0.6, 6.1.5, 6.2.2, 6.3.1, 6.4.0, 6.2.3, 6.3.2, 6.3.3
Support reference count:1
Symptom Severity:Severity 2 - Major
Bug Fix Policy:
It takes a long time for Bitbucket Server to resolve reviewers for a Pull Request when said reviewers are at the bottom of a structure of nested groups.
User directory with lots of groups and users that are at the bottom of nested structure of those groups.
- Have a complicated structure of user directory with multiple levels of nested groups
- Add a group with "read" permissions to a project
- Create a pull request with couple users from that group as reviewers
Pull request is created immediately
Pull request takes up to 10 minutes to create, depending on number of groups
Whenever Bitbucket Server resolves reviewers, it validates those user permissions.
- have permission to user Bitbucket Server (be a licensed user)
- have permission to access the repository pull request is being created in
In order to do that, because of the nested groups structure Bitbucket Server produces a large number of calls to HibernateMembershipDao#search method that fetches users, groups and membership information from the database. When the amount of results this method fetches from the database is large enough, it pollutes Hibernate context to the point when auto flush takes a lot of time. In order to avoid that, Bitbucket Server configured to run this method with transaction that is in "read-only" mode so Hibernate can skip context flushing as there are no changes being made to those entities. However, during PR creation, the method runs in context of outer transaction, which is opened by DefaultPullRequestService#create method and this transaction is "read-write" so this mitigation doesn't work.
Max out users, groups and permissions caches as well as page size for permissions by adding the following into bibucket.properties file:
The numbers must be adjusted accordingly with respect to amount of users and groups in the system.
The workaround seems to bring the time down to 1 minute.