web stats
Mirth Connect v3 - Converting/Upgrading From v2.1 - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 06-08-2016, 06:31 AM
vincent_guaglione vincent_guaglione is offline
Mirth Newb
 
Join Date: Mar 2016
Posts: 24
vincent_guaglione is on a distinguished road
Default 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.
Reply With Quote
  #2  
Old 06-08-2016, 06:52 AM
narupley's Avatar
narupley narupley is offline
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

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.
Reply With Quote
  #3  
Old 06-08-2016, 07:13 AM
vincent_guaglione vincent_guaglione is offline
Mirth Newb
 
Join Date: Mar 2016
Posts: 24
vincent_guaglione is on a distinguished road
Default

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?
Reply With Quote
  #4  
Old 06-08-2016, 07:15 AM
narupley's Avatar
narupley narupley is offline
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
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.
Reply With Quote
  #5  
Old 06-08-2016, 07:39 AM
vincent_guaglione vincent_guaglione is offline
Mirth Newb
 
Join Date: Mar 2016
Posts: 24
vincent_guaglione is on a distinguished road
Default

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?
Reply With Quote
  #6  
Old 06-08-2016, 08:26 AM
vincent_guaglione vincent_guaglione is offline
Mirth Newb
 
Join Date: Mar 2016
Posts: 24
vincent_guaglione is on a distinguished road
Default

Never mind I found my explanation. It's custom script code that was added in one of our deployed channels.
Reply With Quote
Reply

Tags
database, reconfigure, schema, upgrade, v3.3

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 10:26 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Mirth Corporation