How is java heap space related to Mendix cloud plan size?

0
Hi,   My application is running on a Mendix cloud environment and I keep running into a java.lang.OutOfMemoryError: Java heap space error (see attached) while trying to send large fileDocuments though a REST service (ZIP files of 200+MB). I have already upgraded our cloud plan from S-21 STANDARD to L-21 STANDARD with 8GiB memory. When inspecting my metrics dashboard (see attached), I don't see anything unusual.   I have a few questions: Where can I check the java heap space size of a cloud environment? Is there a way to influence this, apart from upgrading my cloud plan? The Mendix modeler allows me to manually set the heap space to (for example) 8000MB through Settings/Configuration/Server/Java heap. When I do this, the error disappears from my localhost. How is this setting related to the heap space of a cloud environment? Can I compare the two in any meaningful way? Does anyone have any ideas on how to accomplish what I want to do? I am calling a POST and I have tried encoding the ZIP file into base64, then adding it to the json body of the request ("Export mapping for the entire request"). adding the fileDocument directly to the REST request ("Binary for the entire request"). CRITICALM2EE: An unhandled error occurred in the MxRuntime. java.lang.OutOfMemoryError: Java heap space at java.base/java.util.Arrays.copyOfRange(Unknown Source) at java.base/java.lang.StringCoding.decodeUTF8(Unknown Source) at java.base/java.lang.StringCoding.decode(Unknown Source) 2024/01/30 11:45:37 [error] 297#0: *10 upstream prematurely closed connection while reading response header from upstream, client: xx.xx.xx.xxx, server: _, request: "POST /debugger/ HTTP/1.1", upstream: "http://127.0.0.1:8081/debugger/", host: "xxxx.apps.eu-1c.mendixcloud.com" at java.base/java.lang.String.<init>(Unknown Source) at java.base/java.lang.String.<init>(Unknown Source) at com.mendix.basis.objectmanagement.member.MendixBinaryFileStoreImpl.parseValueToString(MendixBinaryFileStoreImpl.scala:181) at com.mendix.languages.expressions.VariableExpr$SingleObject.resolveMember(VariableExpr.scala:162) at com.mendix.languages.expressions.VariableExpr.resolvePath(VariableExpr.scala:61) at com.mendix.languages.expressions.VariableExpr.doEvaluate(VariableExpr.scala:40) at com.mendix.languages.expressions.VariableExpr.evaluateExpression(VariableExpr.scala:31) at com.mendix.languages.expressions.Expr.evaluate(Expr.scala:13) at com.mendix.languages.mxexpressions.MxExpressionImpl.evaluate(MxExpressionImpl.scala:25) at com.mendix.languages.mxexpressions.MxExpressionImpl.evaluate(MxExpressionImpl.scala:15) at com.mendix.integration.model.microflow.MicroflowExpression.evaluate(MicroflowExpression.scala:16) at com.mendix.integration.http.HttpBody$.$anonfun$createFromBinary$1(HttpBody.scala:50) at com.mendix.integration.http.HttpBody$$$Lambda$2728/0x0000000100fff040.apply(Unknown Source) at com.mendix.integration.actions.microflow.RestCallAction.prepareRequest(RestCallAction.scala:85) at com.mendix.integration.actions.microflow.RestCallAction.execute(RestCallAction.scala:73) at com.mendix.integration.actions.microflow.RestCallAction.execute(RestCallAction.scala:39) at com.mendix.modules.microflowengine.microflow.impl.MicroflowObject.$anonfun$execute$1(MicroflowObject.scala:32) at com.mendix.modules.microflowengine.microflow.impl.MicroflowObject$$Lambda$2850/0x0000000101077840.apply(Unknown Source) at scala.Option.flatMap(Option.scala:283) at com.mendix.modules.microflowengine.microflow.impl.MicroflowObject.execute(MicroflowObject.scala:29) at com.mendix.modules.microflowengine.microflow.impl.MicroflowImpl.executeAfterBreakingIfNecessary(MicroflowImpl.scala:176) at com.mendix.modules.microflowengine.microflow.impl.MicroflowImpl.executeAction(MicroflowImpl.scala:116) at com.mendix.systemwideinterfaces.core.UserAction.execute(UserAction.java:58) at com.mendix.basis.actionmanagement.CoreActionHandlerImpl.doCall(CoreActionHandlerImpl.scala:71) at com.mendix.basis.actionmanagement.CoreActionHandlerImpl.call(CoreActionHandlerImpl.scala:48) at com.mendix.core.actionmanagement.internal.InternalCoreAction.call(InternalCoreAction.java:57) at com.mendix.basis.actionmanagement.ActionManager.$anonfun$executeSync$2(ActionManager.scala:104) Pat com.mendix.basis.actionmanagement.ActionManager$$Lambda$1932/0x0000000100d0dc40.call(Unknown Source) at com.mendix.util.classloading.Runner$.withContextClassLoader(Runner.scala:20)    
asked
1 answers
0

See the documentation here: https://docs.mendix.com/refguide/runtime-java-errors/ part 2.2. Yes when you have a larger environment your java heap space will be bigger. But any environment can be brought down. So double check what you are doing when your heap space occurs. Try to use amount and offset so you do not have to keep evrerything in memory or use start en end transactions to already offload changes to the database, because otherwise all the data needs to still be in memory in case of a rollback. Hope this helps a bit.

Regards,

Ronald

 

 

answered