Openbravo Issue Tracking System - Openbravo ERP
1. A fake request is created to invoke them as a Servlet
2. That request is used to write the response in as a String representing JavaSript code
3. That string is evaluated, parsed and executed as JavaScript in server
4. To finally set the values it requires
In addition to all the overhead involved in each of the steps described above, step 3 generates bytecodes from JavaScript that are stored in PermGen memory space. This causes excessive PermGen consumption as well as it trigger Major GC Collections even with a low heap use.
All these steps are avoided for SimpleCallout since PR16Q4 0032366
1. Apply attached diff that executes step 3 defined in description 2K times per callout
2. Limit PermGen (ie. 160MB) and monitor JVM
3. Open Sales Order window and click on new (this executes SL_Order_DocType and SL_Order_PriceList callouts)
-> Check JVM graphs during execution (see attached image):
* PermGen rapidly increases
* This is caused to a big number of classes loaded
* Finally, major GC collection cycles are triggered
To detect wrong callouts, apply detect-callouts.diff and execute ClassLoaderTest.
This is the list of 10 Platform callouts obtained in current pi:
- SL_IsDefault
- SL_Column
- SL_AlertRule_SQL
- FixedValueExpressionCallout
- Activation_Message
- SL_ModuleCallout
- SL_Module_Minor_Version
- SL_TableAudit
- DefaultExpressionCallout
- SelectorFieldPropertyCallout
| related to | defect | 0036882 | closed | caristu | There exists some old callouts in core still not refactored to SimpleCallout | |
| depends on | defect | 0036599 | closed | alostale | API change: platform callouts now implement SimpleCallout | |
| related to | design defect | 0036067 | closed | markmm82 | old callouts should be refactored to implement SimpleCallout |
36559.diff (47,853) 2017-08-01 10:00https://issues.openbravo.com/file_download.php?file_id=10938&type=bug