You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ofbiz.apache.org by jl...@apache.org on 2022/11/27 13:19:03 UTC

[ofbiz-framework] 01/03: Fixed: Manufacturing - MRP Run Failure (OFBIZ-12716)

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch release22.01
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git

commit a10e9b36740cce0ea5cdafe38e99e82641c80f28
Author: Jacques Le Roux <ja...@les7arts.com>
AuthorDate: Sun Nov 27 12:47:42 2022 +0100

    Fixed: Manufacturing - MRP Run Failure (OFBIZ-12716)
    
    This was broken by
    "Preventing possible DOS attack done using Java deserialisation" done with
    OFBIZ-12592
    
    The exact solution was not an easy find. Because, despite knowing that it was
    related to serialization filtering (ie using
    '-Djdk.serialFilter=maxarray=100000;maxdepth=20;maxrefs=500;maxbytes=500000'
    in build.gradle) and suspecting that it was not related to a class because
    adding an all classes allowed filter (ie *) to -Djdk.serialFilter, ie
    '-Djdk.serialFilter=*;maxarray=100000;maxdepth=20;maxrefs=500;maxbytes=500000'
    that did not fix the problem.
    
    So it was, at least, one of values of the 4 other parameters initially chosen
    based on default values often suggested.
    
    With trial and error tactic, I finally found I needed only to increase maxrefs*.
    I picked 1000. It should allow bigger MRP needs and should not be an issue for
    DOS attacks.
    
    * The maximum number of internal references
    
    Note that I could have used the "Logging Filter Actions" suggestion at bottom of
    https://docs.oracle.com/javase/10/core/serialization-filtering1.htm
    but trial and error tactic turned to be faster.
    I guess, if I refer to https://access.redhat.com/discussions/5577051, that it
    could be due to using Tomcat or to OFBiz log4j2.xml setting.
    
    Anyway Java 17 seems to have a better solution for that** and we need to turn to
    it in 2023 (EOL of Java 11)
    
    ** https://inside.java/2021/03/02/monitoring-deserialization-activity-in-the-jdk
    
    thanks: Yannong Huang for report
---
 build.gradle | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build.gradle b/build.gradle
index 89ef866c2d..dde2914bd1 100644
--- a/build.gradle
+++ b/build.gradle
@@ -83,7 +83,7 @@ application {
     // jdk.serialFilter is to "Prevent possible DOS attack done using Java deserialisation" (OFBIZ-12592)
     applicationDefaultJvmArgs = project.hasProperty('jvmArgs')
             ? jvmArgs.tokenize()
-            : ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=100000;maxdepth=20;maxrefs=500;maxbytes=500000']
+            : ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=100000;maxdepth=20;maxrefs=1000;maxbytes=500000']
 }
 
 distributions.main.contents.from(rootDir) {