No announcement yet.

Message Storage / Message Pruning Settings

  • Filter
  • Time
  • Show
Clear All
new posts

  • Message Storage / Message Pruning Settings

    We are in the process of converting from Mirth Connect v2.x to v3.x. The Summary tab on channels is a little confusing to me - especially the implication of the slider.

    My objective is to have messages processed in the shortest amount of time, retaining only those mentioned in the subnote on the Message Pruning panel

    (incomplete, errored, and queues messages will not be pruned)
    Which setting is recommended for this case? While Production seems safe, there is a fairly large gain in performance when moving the slider down to Raw. What exactly is the sacrificed as the slider changes Production from Raw to?

    Since the options for "Remove ... on completion" are grayed out when the slider moves farther down, would I be correct in assuming that these higher performance settings will not retain my errored messages.

    Thank you

  • #2
    When the storage is at Production or higher, channels will automatically recover messages if the server suddenly goes down, or you force-halt a channel. For example, say you have 10 destinations, and a message comes in. It gets through 5 destinations and is in the middle of the 6th destination filter/transformer when suddenly the machine gets rebooted for some reason. Since all the necessary stateful information is stored in the database, when Mirth Connect comes back up that message will basically pick back up where it left off without you having to do anything.

    When the stored is at Raw, then only the source Raw content (and source map) is stored. This significantly cuts down on the database inserts/updates that happen throughout the course of a message, so overall performance goes up. But it also means that automatic message recovery cannot happen, since all the necessary information for each destination, etc. isn't being stored anymore. If anything goes wrong the message will be left as unfinished, but because you're still storing the raw message you can still reprocess it if you need to. It's a manual process in that case though, not automatic.

    The Metadata option stores even less data, so the overall performance is even greater. In this case only the message "header" information is stored and none of the content. So you can still view metadata about messages (when it was received, what status it has, any custom metadata columns, basically anything you can see in the message browser table).

    You also cannot enable destination queuing when the storage is set to Raw or lower. Source queuing cannot be enabled when the storage is set to Metadata or lower.
    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

    Nicholas Rupley
    Work: 949-237-6069
    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.

    - How do I foo?
    - You just bar.


    • #3
      Thank you, Nick - your explanation helps clarify the complexity of this settings page.