Openbravo Issue Tracking System - Retail Modules |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0056788 | Retail Modules | Web POS | public | 2024-10-15 14:04 | 2024-11-29 15:35 |
|
| Reporter | malsasua | |
| Assigned To | meriem_azaf | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | scheduled | Resolution | open | |
| Platform | | OS | 5 | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | | |
| Merge Request Status | |
| Review Assigned To | |
| OBNetwork customer | |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0056788: Performance problem on KernelUtils.getModulesOrderedByDependency |
| Description | the function getModulesOrderedByDependency in KernelUtils is not efficient:
https://gitlab.com/openbravo/product/openbravo/-/blob/release/24Q4/modules/org.openbravo.client.kernel/src/org/openbravo/client/kernel/KernelUtils.java?ref_type=heads#L275 [^]
This function is executed for each login, and when a lot of logins are done simultaneously after restart tomcat, it could cause a performance issue |
| Steps To Reproduce | restart tomcat and do multiple logins simultaneously |
| Proposed Solution | similar fix to
https://issues.openbravo.com/view.php?id=49546 [^] |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2024-10-15 14:04 | malsasua | New Issue | |
| 2024-10-15 14:04 | malsasua | Assigned To | => Retail |
| 2024-10-15 14:04 | malsasua | Triggers an Emergency Pack | => No |
| 2024-10-15 17:07 | malsasua | Description Updated | bug_revision_view_page.php?rev_id=28593#r28593 |
| 2024-10-15 17:07 | malsasua | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=28595#r28595 |
| 2024-10-17 06:45 | guillermogil | Assigned To | Retail => Triage Platform Base |
| 2024-10-17 11:18 | AugustoMauch | Assigned To | Triage Platform Base => malsasua |
| 2024-10-17 11:19 | AugustoMauch | Note Added: 0170525 | |
| 2024-10-17 11:20 | AugustoMauch | Status | new => feedback |
| 2024-10-30 08:50 | malsasua | Note Added: 0171136 | |
| 2024-10-30 08:50 | malsasua | Note Deleted: 0171136 | |
| 2024-10-30 08:50 | malsasua | Note Added: 0171137 | |
| 2024-10-30 08:50 | malsasua | Status | feedback => new |
| 2024-11-18 12:04 | guillermogil | Assigned To | malsasua => Triage Platform Base |
| 2024-11-21 09:06 | malsasua | Note Added: 0172380 | |
| 2024-11-29 12:23 | AugustoMauch | Status | new => scheduled |
| 2024-11-29 12:23 | AugustoMauch | Assigned To | Triage Platform Base => meriem_azaf |
| 2024-11-29 15:35 | hgbot | Note Added: 0172780 | |
|
Notes |
|
|
|
|
|
|
|
In the jstack, we saw dozens of threads halted during the process.
The issue occurred because Tomcat was restarted while the stores were open. As a result, when Tomcat started, a large number of login requests came in simultaneously. |
|
|
|
|
Checked with platform team: The KernelUtils.getModulesOrderedByDependency function is cached during the first login.
Possible root cause: If the function takes a few minutes to execute and a significant number of login requests arrive simultaneously after a Tomcat restart, it could result in all threads waiting at this point.
Possible fix: Cache the result of the function when Tomcat starts. While this might slow down the Tomcat startup process, it could prevent thread blockage during login bursts. |
|
|
|
(0172780)
|
|
hgbot
|
|
2024-11-29 15:35
|
|
|