|
Notes |
|
|
(0093984)
|
|
egoitz
|
|
2017-02-01 12:40
|
|
|
You can get also a out of memory error depending on the volume of payments |
|
|
|
|
Please note there is a feature request 0022207 that is the right way to fix this issue. Besides there is a design defect 0022330 related to this topic.
That means that we will try to fix this issue only if it's easy & fast. Spending too much time in this piece of code doesn't make sense and it would be better to work on the redesign instead. |
|
|
|
|
Rejected as duplicated of 0022207
There are two issues that both must be fixed at the same time to make this window working with very high volumens:
1. The Java code doesn't properly manage memory, loading too many records in Hibernate memory, killing the server with high volumens.
Besides the process launches too many queries to the database to get the info to be printed in the grid. This makes the process very slow and also contributes to out of memory problems.
2. The grid where the lines are displayed is not ready for working with high volumens, because it doesn't implement pagination. Thus, if the instance has many lines to shown, it kills the browser trying to render all of them.
In the customer environment that reports this issue there are a total of more than 83K records to display. My browser is unable to render more than 2K records at the same time.
The proper way to fix this is by implementing 0022207.
As a workaround for this problem meanwhile 0022207 is not fixed, I have attached 2 solutions for this problem: the safe one (35127_core.diff + 35127_safe.diff) and the risky one (35127_core.diff + 35127_risky.diff):
* Safe solution: adds an index to core, refactors a query that had important performance problems and, the most important part, adds a limit of 1K records to be shown. This way we workaround problems explained in #1 and #2 and the user can start creating remittance batches of 1K records.
* Risky solution: adds an index to core, heavily refactor Java code to improve memory management (with this patch we fix Out of Memory exceptions) and to improve SQL performance (now the process is finished in less than 15 seconds in my test for the 83K records). However it has two important problems: it might introduce regressions because the changes are really major and it won't fix the browser rendering problems, so depending on the number of records your browser will probably crash.
As a conclusion, I would recommend to apply the safe patch and work in batches of 1K records.
This window is clearly obsolete and should be refactor instead of investing more time |
|
35127_core.diff (669) 2017-02-16 09:31