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

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Retail Modules] Web POSmajorsometimes2017-11-16 07:392017-12-22 13:52
ReporterguillermogilView Statuspublic 
Assigned Tomarvintm 
PriorityimmediateResolutionfixedFixed in VersionRR17Q4
StatusclosedFix in branchFixed in SCM revision7f1679d43493
ProjectionnoneETAnoneTarget VersionRR17Q4
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tomigueldejuana
Regression levelProduction - Confirmed Stable
Regression date2016-01-05
Regression introduced in releaseRR16Q2
Regression introduced by commit [^]
Triggers an Emergency PackNo

0037304: 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
hgbot (developer)
2017-12-19 18:49

Repository: retail/backports/3.0RR17Q4/
Changeset: 7f1679d434938af59b75e26c1197476aef624cab
Author: Antonio Moreno <antonio.moreno <at>>
Date: Tue Dec 19 18:49:11 2017 +0100
URL: [^]

Fixed issue 37304. 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/
M src/org/openbravo/mobile/core/process/
migueldejuana (developer)
2017-12-22 13:52


- 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 => RR17Q4
2017-12-19 18:40 marvintm Assigned To Retail => marvintm
2017-12-19 18:49 hgbot Checkin
2017-12-19 18:49 hgbot Note Added: 0101148
2017-12-19 18:49 hgbot Status scheduled => resolved
2017-12-19 18:49 hgbot Resolution open => fixed
2017-12-19 18:49 hgbot Fixed in SCM revision => [^]
2017-12-22 13:52 migueldejuana Review Assigned To => migueldejuana
2017-12-22 13:52 migueldejuana Note Added: 0101239
2017-12-22 13:52 migueldejuana Status resolved => closed
2017-12-22 13:52 migueldejuana Fixed in Version => RR17Q4

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker