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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0037305
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Retail Modules] Web POSmajorsometimes2017-11-16 07:392017-12-22 08:42
ReporterguillermogilView Statuspublic 
Assigned Tomarvintm 
PriorityimmediateResolutionfixedFixed in VersionRR17Q3.3
StatusclosedFix in branchFixed in SCM revision3840f870f2cb
ProjectionnoneETAnoneTarget VersionRR17Q3.2
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Merge Request Status
Review Assigned Tomigueldejuana
OBNetwork customerOBPS
Support ticket
Regression levelProduction - Confirmed Stable
Regression date2016-01-05
Regression introduced in releaseRR16Q2
Regression introduced by commithttps://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/727a4f04e3e023624bbdc36cdb682e95304129ad [^]
Triggers an Emergency PackNo
Summary

0037305: Java Heap Memory can rise on login if batch size is big

DescriptionJava Heap Memory can rise on login if batch size is big and you have a big batch size and an small xmx.
Steps To ReproduceWith a lot of products, big batch size (> 60000) and an small xmx in CATALINA_OPTS (1GB)
Try to login in WebPOS
You will have a Java heap memory.
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
blocks defect 0037301 closedmarvintm Java Heap Memory can rise on login if batch size is big 

-  Notes
(0101149)
hgbot (developer)
2017-12-19 18:50

 Repository: retail/backports/3.0RR17Q3.2/org.openbravo.mobile.core
Changeset: 3840f870f2cb804eacae68a42667e1d72c8e8c28
Author: Antonio Moreno <antonio.moreno <at> openbravo.com>
Date: Tue Dec 19 18:50:14 2017 +0100
URL: http://code.openbravo.com/retail/backports/3.0RR17Q3.2/org.openbravo.mobile.core/rev/3840f870f2cb804eacae68a42667e1d72c8e8c28 [^]

Fixed issue 37305. Avoid usage of intermediate StringWriters so that response doesn't take too much heap.
> The main problem is that the two intermediate StringWriters accumulate the whole response before it is sent back to the client. This causes Java Heap memory problems in case the batching is set to a big amount, and concurrency is high.
> The solution is to remove these intermediate StringWriters. We have verified that the messages are not lost even in the case of low level database problems, because the client correctly detects the problem, and doesn't remove the records, and instead tries to send them again in the next synchronization.

---
M src/org/openbravo/mobile/core/process/MobileService.java
M src/org/openbravo/mobile/core/process/MobileServiceProcessor.java
---
(0101196)
migueldejuana (viewer)
2017-12-22 08:42

 Reviewed

- Issue History
Date Modified Username Field Change
2017-11-16 10:27 marvintm Type design defect => backport
2017-11-16 10:27 marvintm Target Version => RR17Q3.2
2017-12-19 18:40 marvintm Assigned To Retail => marvintm
2017-12-19 18:50 hgbot Checkin
2017-12-19 18:50 hgbot Note Added: 0101149
2017-12-19 18:50 hgbot Status scheduled => resolved
2017-12-19 18:50 hgbot Resolution open => fixed
2017-12-19 18:50 hgbot Fixed in SCM revision => http://code.openbravo.com/retail/backports/3.0RR17Q3.2/org.openbravo.mobile.core/rev/3840f870f2cb804eacae68a42667e1d72c8e8c28 [^]
2017-12-22 08:42 migueldejuana Review Assigned To => migueldejuana
2017-12-22 08:42 migueldejuana Note Added: 0101196
2017-12-22 08:42 migueldejuana Status resolved => closed
2017-12-22 08:42 migueldejuana Fixed in Version => RR17Q3.3

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker