Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformminorsometimes2017-04-25 18:242018-01-03 12:38
ReporterJONHMView Statuspublic 
Assigned Toinigosanchez 
PriorityurgentResolutionfixedFixed in Version3.0PR18Q1
StatusclosedFix in branchFixed in SCM revision4524f5da317f
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toalostale
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0035838: Bad performance in alert window when having +20000 records in ad_alert and many of them are solved

DescriptionWhen having +200000 records in ad_alert, and many of them are solved, it causes a performance issue.
Steps To Reproduce- In an environment with +200000 alerts

1) Login with Openbravo user and press the [Alert] button on the top of the screen
2) It shows a timeout: 'no records to show' while java is consuming the memory causing a performance issue
Proposed SolutionFilter by not solved alerts in the getWhereAndFilterClause() function of ADAlertDatasourceService class
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0036605 closedinigosanchez unneeded datasource requests opening alert management window 
related to defect 0037214 closedinigosanchez It is possible to produce a server crash executing on the sql query window a query returning thousands of records 

-  Notes
hgbot (developer)
2017-11-09 10:01

Repository: erp/devel/pi
Changeset: 4524f5da317f97b8510233fd4d905982e0c4d53a
Author: Inigo Sanchez <inigo.sanchez <at>>
Date: Wed Nov 08 12:25:15 2017 +0100
URL: [^]

Fixes issue 35838: Improved the performance in Alert Management window

When you had several alerts (the problem was reported with +20000 alerts) and the Alert Management
window was opening, there was a performance problem: The alerts weren't show, java was consuming
the memory,etc.

Several refactors and improvements have been done in order to improve the performance in Alert
Management window:

- The getWhereAndFilterClause method was performing twice per alert status. It is removed the
invocation from the fetch method in ADAlertDatasourceService because it is done in the fetch method
of the super class.
- It is not neccesary to retrieves the full alert object when only the alert ID is needed. The same
for AlertRule.
- Now the status of the alert is take into account in the queries in order to retrieves from the DB
only the alerts that should be needed.
- StringBuilder is used instead of String when concatenate several IDs.

Now the performance of the window is improvement a lot. For example, having more than 20000 alerts,
it has been reduce the time from 40.1 seconds to 0.6 seconds (Times in DataSourceServlet.doFetch)
showing to the user the same information.

M modules/org.openbravo.client.application/src/org/openbravo/client/application/
hgbot (developer)
2017-11-10 11:54

Repository: erp/devel/pi
Changeset: 873652fe3cd4485c3011e2369ebcea703895a3e6
Author: Asier Lostalé <asier.lostale <at>>
Date: Fri Nov 10 11:49:58 2017 +0100
URL: [^]

related with bug 35838: performance issues in Alert window

  Some minor code clean up:
   - Format SQL to make it more readable
   - Removed clutter + duplicity handling elements in map
   - Use parameterized statements instead of string concatenation to generate query
   - Prevent expensive debug message generation if it won't be logged

M modules/org.openbravo.client.application/src/org/openbravo/client/application/
alostale (developer)
2017-11-10 11:56

reviewed + tested
inigosanchez (developer)
2017-11-10 12:49

Times in DataSourceServlet.doFetch having more than 20000 Alerts:
- Open Alert Management window. Before: 40100 ms. After improvements: 600 ms.
hudsonbot (developer)
2018-01-03 12:38

A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: [^]
Maturity status: Test
hudsonbot (developer)
2018-01-03 12:38

A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: [^]
Maturity status: Test

- Issue History
Date Modified Username Field Change
2017-04-25 18:24 JONHM New Issue
2017-04-25 18:24 JONHM Assigned To => platform
2017-04-25 18:24 JONHM Modules => Core
2017-04-25 18:24 JONHM Triggers an Emergency Pack => No
2017-04-25 18:25 JONHM Severity major => minor
2017-04-26 08:28 alostale Tag Attached: Performance
2017-04-26 08:28 alostale Status new => acknowledged
2017-08-04 12:34 alostale Relationship added related to 0036605
2017-08-04 12:50 alostale Priority high => urgent
2017-10-24 10:47 inigosanchez Status acknowledged => scheduled
2017-10-24 10:47 inigosanchez Assigned To platform => inigosanchez
2017-11-06 13:12 alostale Relationship added related to 0037214
2017-11-09 10:01 hgbot Checkin
2017-11-09 10:01 hgbot Note Added: 0100370
2017-11-09 10:01 hgbot Status scheduled => resolved
2017-11-09 10:01 hgbot Resolution open => fixed
2017-11-09 10:01 hgbot Fixed in SCM revision => [^]
2017-11-09 10:06 inigosanchez Review Assigned To => alostale
2017-11-10 11:54 hgbot Checkin
2017-11-10 11:54 hgbot Note Added: 0100420
2017-11-10 11:56 alostale Note Added: 0100421
2017-11-10 11:56 alostale Status resolved => closed
2017-11-10 11:56 alostale Fixed in Version => 3.0PR18Q1
2017-11-10 12:49 inigosanchez Note Added: 0100422
2018-01-03 12:38 hudsonbot Checkin
2018-01-03 12:38 hudsonbot Note Added: 0101387
2018-01-03 12:38 hudsonbot Checkin
2018-01-03 12:38 hudsonbot Note Added: 0101400

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker