Announcement

Collapse
No announcement yet.

Heap Size error at 6GB?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Heap Size error at 6GB?

    I am processing RTF files and they are going through the channel succesfully. However, when I view the log monitor and select a message to look at, I get the error, "There was an out of memory error when trying to retrieve message content. Increase your heap size and try again."

    The Mirth Appliance shows the heap size set to 6GB which should be large enough to handle this easily. Is there another configuration setting that needs to be changed as well?

    I've searched and found reference to the vmoptions file, but it sounds like that is the file to change the available heap size selections. I'm also unsure where that would be in case it IS where I want to adjust. But 6GB not being enough? Either this doesn't relate to the viewing within the monitor, or something else must be up.

  • #2
    Are you parsing the RTF files? If not, trying changing the data types to RAW and set the entire message as an attachment. It's a start anyway...

    -= Jack Haines : Founder/CEO of Healthcare Integrations, LLC
    -= [email protected]
    -= Mirth Connect (Advanced)-certified
    -= Gold member of HL7.org
    -= Available for Mirth Connect channel development and consultation! Schedule a FREE call with me at https://calendly.com/jackhaines

    Comment


    • #3
      vmoptions was to change the permgen value. Java does that dynamically now.

      Comment


      • #4
        Originally posted by jackwhaines View Post
        Are you parsing the RTF files? If not, trying changing the data types to RAW and set the entire message as an attachment. It's a start anyway...
        I'm not sure what you mean by parsing the RTF files. We're passing it downstream.

        Comment


        • #5
          Storing the rtf as a mirth attachment rather than keeping it as part of the message will cut down on memory usage quite a bit. If you are only passing it downstream, this is a good use case for attachments.

          Comment


          • #6
            Originally posted by agermano View Post
            Storing the rtf as a mirth attachment rather than keeping it as part of the message will cut down on memory usage quite a bit. If you are only passing it downstream, this is a good use case for attachments.
            Thanks agermano. You replied in my other thread on how to go about setting that up. After I enter the expression & MIME type as you outlined, does the OBX-5 storing/re-attaching happen in any way that I can notice it? Or will it still look the same through the log monitor from my end? The main problem I'm stuck on at this juncture is that I can't click & view the message in the log. I assume the data storage will lower the memory usage and allow me to view in that method?

            Comment


            • #7
              You do not see the token being replaced in the message viewer, but if you would like to verify it is working correctly you can switch your destination to a file writer and look at the file produced. In the message viewer, there should also be an Attachments tab where you can see the attachment. I don't believe that mirth has an integrated rtf viewer, but you should be able to right-click the attachment and download it.

              Comment


              • #8
                Originally posted by agermano View Post
                You do not see the token being replaced in the message viewer, but if you would like to verify it is working correctly you can switch your destination to a file writer and look at the file produced. In the message viewer, there should also be an Attachments tab where you can see the attachment. I don't believe that mirth has an integrated rtf viewer, but you should be able to right-click the attachment and download it.
                Thanks. I don't need to view the actual RTF, just interested in reviewing the message in case I have to look at the actual HL7 message. So the token thing should work for that purpose, if it indeed saves me enough space that the monitor can load the message to view w/o running into the heap size problem again.

                I also thought about creating a file folder to drop to as well, but would prefer the viewer for quick access when needed. If the attachment/token idea created an attachment tab for me to view that section of a message, then that would be perfect as well. I'll look in the morning!

                Here's a question - is the 6GB heap size the absolute limit or is there a way to expand beyond that "if we wanted to"? I realize it would likely depend on the server, but assuming we have plenty of memory to spare...

                Comment


                • #9
                  /opt/mirthconnect/conf

                  edit the file mirth.properties...

                  administrator.maxheapsize = 8G

                  requires a restart of the servervice.
                  Last edited by cory_cole; 12-16-2019, 11:50 AM.

                  Comment


                  • #10
                    Originally posted by cory_cole View Post
                    /opt/mirthconnect/conf

                    edit the file mirth.properties...

                    administrator.maxheapsize = 8G

                    requires are restart of the servervice.
                    Thank you! So far the save attachment seems to be working well, pending endpoint review & approval, but this is good to have if I need to go back to that.

                    Comment

                    Working...
                    X