3

Because of too low set of max limit of processes and sessions in an Oracle DB, sometimes the following error occurs in mirth:

DBConnection - java.sql.SQLException: Listener refused the connection with the following error: ORA-12516, TNS:listener could not find available handler with matching protocol stack

due to dbConn.executeCachedQuery(SQLStatement) with the DatabaseConnection Class in Mirth

So these are my questions:

  1. Is there any way to throw this response/exception in the channel?
  2. Is all data of the SQL query with the exception "lost", if this error occurs or is there an automatic retry?
  3. And is there a best practice to handle this (e.g. to check first the the connection with a getConnection() method)?
th_lo
  • 461
  • 3
  • 18

1 Answers1

3

I'll answer your questions in order:

1) If you are using the javascript connector, then you should have this in a try catch when you initiate the connection. In the catch, just put the error as Logger.Error(exceptionGoesHere).

If you are using the db connector this should get throw automatically in the logs. To make sure you have logging enabled at the channel level, access the Mirth Connect Server Manager, click on the Server tab and ensure that Channel Log Level is at least set to Error.

2) The way that Mirth Connect works, every time the message is initiated it will hit certain points of the Mirth DB to save the state of the message at that point in time. It's how Mirth guarantees message delivery. With that being said, you can always 'retry' the send manually. Otherwise, if you are using the DB connector there's an option that handles this for you under the Database Reader Settings section. The retry gives you the option to select the number of retries as well as the Retry interval in ms. When I was working there, by default it was set to 3 retries after 10 seconds.

3) Use the default database connector. Everything's already built in for you. Put the extra processing in the transformer to handle anything else. Don't try to re-invent the wheel if everything is already built is the best practice.

If you insist on using a code solution, then make sure all of your code is in a try catch, and make sure your catch is actually logging out the error exception.

that_guy
  • 56
  • 3
  • I think default db connector isn't always the best solution: [Connection reset by peer problem](http://www.mirthcorp.com/community/forums/showthread.php?t=5144) – th_lo Jan 15 '20 at 11:29
  • But thank you for your answers! Unfortunately I have to use a code Template to get out the parameters. Therefore only a javascript query is possible. All queries are in a try catch error statements. But maybe and they are cascaded, so there are 3 queries in one function. The first try catch statement doesn't throw an exception and only logs with logger.error. Maybe I have to adjust the function to throw here an exception to get an error also in the channel, not only in the logger. – th_lo Jan 15 '20 at 11:30
  • You might have to have multiple try/catches within each other for the desired result. That issue is very odd, make sure to post your problem in the forums, I thought this issue was resolved in the later versions. Which version are you using? – that_guy Jan 15 '20 at 15:59
  • current version is 3.4.1.770 – th_lo Jan 16 '20 at 11:30
  • I suggest asking on the mirth forums or joining the slack channel. The community is pretty responsive in answering questions. – that_guy Jan 16 '20 at 18:55
  • ok, will do. didn't know that there is also a slack channel. thank you – th_lo Jan 17 '20 at 10:18