-
Suggestion
-
Resolution: Fixed
-
None
The DefaultLicensedUserCountCache in Stash and Bitbucket DC versions up to and including 4.7 uses a Spring Cache (backed by a Hazelcast IMap) and a Hazelcast IAtomicLong internally. In some scenarios, this can cause the licensed user count computation on one cluster node to block waiting for another cluster node, which in the event of OS or JVM issues (e.g., excessive GC pauses) may be slow or unresponsive.
In Bitbucket Data Center 4.8.0 and higher, this has been replaced with the SchedulerService and TopicService which do not block on other cluster nodes even if they are affected by OS or JVM issues.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[BSERV-8889] Replace Spring Cache and IAtomicLong in DefaultLicensedUserCountCache with TopicService and SchedulerService
| Workflow | Original: JAC Suggestion Workflow [ 3395974 ] | New: JAC Suggestion Workflow 3 [ 3618363 ] |
| Status | Original: RESOLVED [ 5 ] | New: Closed [ 6 ] |
| Workflow | Original: BSERV Suggestions Workflow [ 2686587 ] | New: JAC Suggestion Workflow [ 3395974 ] |
| Workflow | Original: Stash Workflow [ 1423718 ] | New: BSERV Suggestions Workflow [ 2686587 ] |
| Status | Original: Closed [ 6 ] | New: Resolved [ 5 ] |
| Remote Link | Original: This issue links to "Page (Extranet)" [ 291485 ] |
| Remote Link | New: This issue links to "Page (Extranet)" [ 291485 ] |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Quality Review [ 10029 ] | New: Closed [ 6 ] |
| Description |
Original:
The {{DefaultLicensedUserCountCache}} in Stash and Bitbucket DC versions up to and including 4.7 uses a Spring {{Cache}} backed by a Hazelcast {{IMap}}, and a Hazelcast {{IAtomicLong}} internally. In some scenarios, this can cause the licensed user count computation on one cluster node to block waiting for another cluster node, which in the event of OS or JVM issues (e.g., excessive GC pauses) may be slow or unresponsive.
In Bitbucket Data Center 4.8.0 and higher, this has been replaced with the {{SchedulerService}} and {{TopicService}} which do not block on other cluster nodes even if they are affected by OS or JVM issues. |
New:
The {{DefaultLicensedUserCountCache}} in Stash and Bitbucket DC versions up to and including 4.7 uses a Spring {{Cache}} (backed by a Hazelcast {{IMap}}) and a Hazelcast {{IAtomicLong}} internally. In some scenarios, this can cause the licensed user count computation on one cluster node to block waiting for another cluster node, which in the event of OS or JVM issues (e.g., excessive GC pauses) may be slow or unresponsive.
In Bitbucket Data Center 4.8.0 and higher, this has been replaced with the {{SchedulerService}} and {{TopicService}} which do not block on other cluster nodes even if they are affected by OS or JVM issues. |
| Description |
Original:
The {{DefaultLicensedUserCountCache}} in Stash and Bitbucket DC versions up to and including 4.7 use a Spring {{Cache}} backed by a Hazelcast {{IMap}}, and a Hazelcast {{IAtomicLong}} internally. In some scenarios, this can cause the licensed user count computation on one cluster node to block waiting for another cluster node, which in the event of OS or JVM issues (e.g., excessive GC pauses) may be slow or unresponsive.
In Bitbucket Data Center 4.8.0 and higher, this has been replaced with the {{SchedulerService}} and {{TopicService}} which do not block on other cluster nodes even if they are affected by OS or JVM issues. |
New:
The {{DefaultLicensedUserCountCache}} in Stash and Bitbucket DC versions up to and including 4.7 uses a Spring {{Cache}} backed by a Hazelcast {{IMap}}, and a Hazelcast {{IAtomicLong}} internally. In some scenarios, this can cause the licensed user count computation on one cluster node to block waiting for another cluster node, which in the event of OS or JVM issues (e.g., excessive GC pauses) may be slow or unresponsive.
In Bitbucket Data Center 4.8.0 and higher, this has been replaced with the {{SchedulerService}} and {{TopicService}} which do not block on other cluster nodes even if they are affected by OS or JVM issues. |
| Description |
Original:
The {{DefaultLicensedUserCountCache}} in Stash and Bitbucket DC versions up to and including 4.7.0 use a Spring {{Cache}} backed by a Hazelcast {{IMap}}, and a Hazelcast {{IAtomicLong}} internally. In some scenarios, this can cause the licensed user count computation on one cluster node to block waiting for another cluster node, which in the event of OS or JVM issues (e.g., excessive GC pauses) may be slow or unresponsive.
In Bitbucket Data Center 4.8.0 and higher, this has been replaced with the {{SchedulerService}} and {{TopicService}} which do not block on other cluster nodes even if they are affected by OS or JVM issues. |
New:
The {{DefaultLicensedUserCountCache}} in Stash and Bitbucket DC versions up to and including 4.7 use a Spring {{Cache}} backed by a Hazelcast {{IMap}}, and a Hazelcast {{IAtomicLong}} internally. In some scenarios, this can cause the licensed user count computation on one cluster node to block waiting for another cluster node, which in the event of OS or JVM issues (e.g., excessive GC pauses) may be slow or unresponsive.
In Bitbucket Data Center 4.8.0 and higher, this has been replaced with the {{SchedulerService}} and {{TopicService}} which do not block on other cluster nodes even if they are affected by OS or JVM issues. |
| Status | Original: To be reviewed [ 10026 ] | New: Quality Review [ 10029 ] |