Mirth Connect
  1. Mirth Connect
  2. MIRTH-3828

Stackoverflow while restoring config from 3.2.1 to 3.3.1

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Administrator
    • Labels:
      None
    • Environment:
      windows x64
    • Operating System:
      Windows 7
    • Database:
      Apache Derby

      Description

      While restoring a config from 3.2.1 to a 3.3.1 this error occurs:

      ERROR 2015-11-02 15:18:51,876 [qtp1780462417-45] com.mirth.connect.server.servlets.ConfigurationServlet: java.lang.StackOverflowError
      at java.util.regex.Pattern$GroupHead.match(Unknown Source)
      at java.util.regex.Pattern$Loop.match(Unknown Source)
      at java.util.regex.Pattern$GroupTail.match(Unknown Source)
      at java.util.regex.Pattern$BranchConn.match(Unknown Source)
      at java.util.regex.Pattern$CharProperty.match(Unknown Source)
      at java.util.regex.Pattern$Branch.match(Unknown Source)
      at java.util.regex.Pattern$GroupHead.match(Unknown Source)
      at java.util.regex.Pattern$Loop.match(Unknown Source)

      This config file can be restored with success on 3.2.1.
      I have tested with other config files on this 3.3.1 and they work so it is a particular issue with this config file.

      1. mirth.log
        252 kB
        Hugo Soares
      2. stack.txt
        70 kB
        Paul Lewis

        Issue Links

          Activity

          Hide
          Hugo Soares added a comment -

          Log file with full stacktrace

          Show
          Hugo Soares added a comment - Log file with full stacktrace
          Hide
          Paul Lewis added a comment - - edited

          I've noticed this also, but I cannot get it to occur reliably (the same config file will restore without issue on the first or second or third attempt). Occurs in Client and Command.
          I've attached a similar stack trace.

          Server is installed on Linux, running Command from Linux, running client from Win7 x64

          Show
          Paul Lewis added a comment - - edited I've noticed this also, but I cannot get it to occur reliably (the same config file will restore without issue on the first or second or third attempt). Occurs in Client and Command. I've attached a similar stack trace. Server is installed on Linux, running Command from Linux, running client from Win7 x64
          Hide
          Hugo Soares added a comment -

          In my case I needed to remove a code template from the original file in order to successfully import into 3.3.1.
          Basically this fucntion code template had no function declaration.(the code was commented)

          /**
          function etc(){
          }
          */

          Show
          Hugo Soares added a comment - In my case I needed to remove a code template from the original file in order to successfully import into 3.3.1. Basically this fucntion code template had no function declaration.(the code was commented) /** function etc(){ } */
          Hide
          Ortwin Donak added a comment - - edited

          This behavior also occurs if the javascript doc of a function is too detailed (using many tags). The function parsing the header seems to be recursive and thus finally by causing an overflow of the stack.

          A simple fix is to increase the stack size. E.g. changing the first line of the resource section in Mirth-Aministrator.jnlp to the following, fixes the issue:

          <j2se href="http://java.sun.com/products/autodl/j2se" max-heap-size="2048m" version="1.6+" java-vm-args="-Xss1M"/>

          For the mirth service add the option -Xss1M to mcservice.vmoptions

          Parameter -Xss determines the stack size. Default on X86_64 systems is 128k

          Details: https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html#wp1024112

          Please find further details in this thread: http://www.mirthproject.org/community/forums/showthread.php?t=217831

          Show
          Ortwin Donak added a comment - - edited This behavior also occurs if the javascript doc of a function is too detailed (using many tags). The function parsing the header seems to be recursive and thus finally by causing an overflow of the stack. A simple fix is to increase the stack size. E.g. changing the first line of the resource section in Mirth-Aministrator.jnlp to the following, fixes the issue: <j2se href="http://java.sun.com/products/autodl/j2se" max-heap-size="2048m" version="1.6+" java-vm-args="-Xss1M"/> For the mirth service add the option -Xss1M to mcservice.vmoptions Parameter -Xss determines the stack size. Default on X86_64 systems is 128k Details: https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html#wp1024112 Please find further details in this thread: http://www.mirthproject.org/community/forums/showthread.php?t=217831
          Hide
          Nick Rupley added a comment -

          Duplicates MIRTH-4064

          Show
          Nick Rupley added a comment - Duplicates MIRTH-4064

            People

            • Assignee:
              Unassigned
              Reporter:
              Hugo Soares
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development