Announcement

Collapse
No announcement yet.

Mirth Connect v3 - Converting/Upgrading From v2.1

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

  • Mirth Connect v3 - Converting/Upgrading From v2.1

    I have a question regarding upgrading Mirth from version 2.1 to version 3.x.

    We are performing this upgrade in an effort to solve some performance and message purging issues.

    Part of this upgrade is to point the v3 version of Mirth to a new Mirth database. Our procedures include shutting down the current production v2.1 Mirth, letting all queued messages finish processing, then copying the database to a new server (part of our infrastructure upgrade). Our new Mirth instance (running on a new server) will point to this new database. We will then start this new Mirth instance.

    We've run through this scenario twice in both our dev and test environments so we know this works. But, I'm asking the community if there are any other items I should be taking into account here before performing this upgrade on our prod system?

    When Mirth is started, it does upgrade the database schema and this is expected. However, I have noticed that Mirth will queue up messages that I believe it had already processed on the old system. I expected that since all queued messages on the old system had cleared, and all the channels had been stopped, performing a database copy to a new server then starting the new Mirth instance against this new database would have resulted in no additional messages being queued up.

    So I'm asking if this scenario I have described can be explained, and also if there is anything else I need to review (specific configurations, specific database table contents, etc.) before I perform this upgrade?

    Any input is appreciated.

  • #2
    Version 2.x stored queued messages on the filesystem (appdata/queuestore), and it was possible, depending on race conditions when the server is stopped, that a queued message would get sent, but the file in the queuestore would not yet get deleted. So when the server is next started up, that queued message would attempt to be sent again.

    That is no longer an issue in 3.x at all, because queued messages are stored in the same database that all other message data is stored.

    One thing I would say is to first upgrade on a test environment. We deprecate certain things accessible to the user in JavaScript, and keep that deprecation around for a few versions, after which the deprecation is removed. So if you're upgrading to the newest version (3.4.1) from a really old version (2.x), some things that were deprecated have already been removed, and code in channels might stop working.

    One example is the change of the variable "messageObject" to "connectorMessage". Back when 3.0.0 was released, using "messageObject" still worked, but a deprecation warning was sent to the server log whenever you used it. However in 3.2 (year and a half later), that deprecation was removed, such that any remaining references to "messageObject" would not work at all. The expectation is that users should have updated their scripts by then.
    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.

    Comment


    • #3
      So there should be no queuestore on the file system on the new server, correct? Since this server was installed with a new copy of Mirth 3.3.2, it should not contain a queuestore on the file system. Is this the correct assumption?

      Comment


      • #4
        Originally posted by vincent_guaglione View Post
        So there should be no queuestore on the file system on the new server, correct? Since this server was installed with a new copy of Mirth 3.3.2, it should not contain a queuestore on the file system. Is this the correct assumption?
        If it's a completely new installation then yeah.
        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.

        Comment


        • #5
          Hmm... this is interesting because I'm seeing queued messages on the new instance although the install was a fresh copy of 3.3.2. I don't see an appdata/queuestore folder on this machine so now I'm confused.

          Anything else I can check?

          Comment


          • #6
            Never mind I found my explanation. It's custom script code that was added in one of our deployed channels.

            Comment

            Working...
            X