Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0035127
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Modules] Remittancemajoralways2017-02-01 12:382017-02-16 09:32
ReporteregoitzView Statuspublic 
Assigned Tovmromanos 
PrioritynormalResolutionduplicateFixed in Version
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Regression date
Regression introduced by commit45320
Regression level
Review Assigned Tovmromanos
Regression introduced in release
Summary

0035127: Performance problems adding order or invoices to a remmitance

Descriptionwhen there are a thousands of payment ins the grid of the add order or invoices popup takes long to be loaded if you click on the show alternative check box.
Steps To ReproduceOpen the popup on an environment with a lot of payment in pending (pending sales invoices)
TagsNo tags attached.
Attached Filesdiff file icon 35127_core.diff [^] (669 bytes) 2017-02-16 09:31 [Show Content]
diff file icon 35127_safe.diff [^] (1,916 bytes) 2017-02-16 09:32 [Show Content]
diff file icon 35127_risky.diff [^] (46,218 bytes) 2017-02-16 09:32 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]
duplicate of feature request 0022207 newTriage Omni OMS Select Orders or Invoices through the Pick and Execute pattern 
related to design defect 0022330 newTriage Omni OMS Improve performance first time you click on "select orders or invoices" button in Remittance header 

-  Notes
(0093984)
egoitz (manager)
2017-02-01 12:40

You can get also a out of memory error depending on the volume of payments
(0094275)
vmromanos (manager)
2017-02-13 17:12

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.
(0094379)
vmromanos (manager)
2017-02-16 09:31

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

- Issue History
Date Modified Username Field Change
2017-02-01 12:38 egoitz New Issue
2017-02-01 12:38 egoitz Assigned To => platform
2017-02-01 12:38 egoitz Regression introduced by commit => 45320
2017-02-01 12:38 egoitz Resolution time => 1488322800
2017-02-01 12:39 egoitz Assigned To platform => Triage Finance
2017-02-01 12:39 egoitz Category New selectors => Remittance
2017-02-01 12:40 egoitz Note Added: 0093984
2017-02-13 17:12 vmromanos Note Added: 0094275
2017-02-13 17:12 vmromanos Relationship added related to 0022207
2017-02-13 17:13 vmromanos Relationship added related to 0022330
2017-02-13 21:56 markmm82 Assigned To Triage Finance => Sanjota
2017-02-14 09:17 jmonfort Issue Monitored: jmonfort
2017-02-14 09:53 vmromanos Assigned To Sanjota => vmromanos
2017-02-15 11:27 vmromanos Status new => acknowledged
2017-02-16 09:08 vmromanos Status acknowledged => scheduled
2017-02-16 09:30 vmromanos Review Assigned To => vmromanos
2017-02-16 09:31 vmromanos Relationship replaced duplicate of 0022207
2017-02-16 09:31 vmromanos Note Added: 0094379
2017-02-16 09:31 vmromanos Status scheduled => closed
2017-02-16 09:31 vmromanos Resolution open => duplicate
2017-02-16 09:31 vmromanos File Added: 35127_core.diff
2017-02-16 09:32 vmromanos File Added: 35127_safe.diff
2017-02-16 09:32 vmromanos File Added: 35127_risky.diff


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker