search

rbeckman-nextgen / test-mc

test-migration
1 stars 0 forks source link

Persistent blocking of Mirth JDBC postgres outgoing connector:jdbc Pool not open #902

Open rbeckman-nextgen opened 5 years ago

rbeckman-nextgen commented 5 years ago

After several weeks without problem, We encountered a problem of persistent blocking of Mirth JDBC postgres outgoing connector. The channel is in the folowing context:

Mirth-lan (outgoing jdbc connector)-->firewall/DMZ--> Postgres 8.3.9 database

This issue places the whole Mirth channel in the blocked state unable to produce an error for the dashboard until the Mirth server is manually stopped and restarted. Only after restarting the server Mirth, the error in the attached doc was produced. This error is different from what we got after an intentional blocking of the firewall. (test which produces an error for the channel non-blocking after a 2 minutes timout, then well managed by Mirth)

Imported Issue. Original Details: Reporter: bruno.martin@chu-dijon.fr Created: 2011-03-08T08:08:10.000-0800

rbeckman-nextgen commented 5 years ago

Error obtained after Mirth server restart & Sample channel (see first destination)

Imported Comment. Original Details: Author: bruno.martin@chu-dijon.fr Created: 2011-03-08T08:14:18.000-0800

rbeckman-nextgen commented 5 years ago

other example of blocked Mirth outbound connector (here sftp): pool not open (org.apache.commons.pool problem ?)

Imported Comment. Original Details: Author: bruno.martin@chu-dijon.fr Created: 2011-03-16T11:03:21.000-0700

rbeckman-nextgen commented 5 years ago

Have you reproduced the same error in Mirth Connect 2.x? Almost every library was upgraded for 2.0, in case the problem lies in one of those libraries. At this point I would recommend trying 2.1 RC1.

Imported Comment. Original Details: Author: jacobb Created: 2011-03-16T11:39:19.000-0700

rbeckman-nextgen commented 5 years ago

The observation was made ​​in production with Mirth 1.8.2 (Windows 2003 32-bit JDBC access through a firewall) and (Suse Linux 64 x_86 SLES 11 SP1 for SFTP access through a firewall). We will evaluate Mirth 2.1 RC in the coming days.

However, the incident is not consistently reproducible. (Only 2 incidents between February 26 and March 16 with a daily transfer in production) We had done thousands of transfers for several weeks in test context, with transfers jdbc / sftp through a firewall, without problems.

I will keep you informed of the result with the new Mirth 2.1 version, with the benefit of Apache.commons 2.0 components.

Best regards,

Bruno Martin

Chef de Projet Infrastructure EAI Direction des Systèmes d'Information Centre Hospitalier Universitaire de Dijon Tél : 03.80.29.31.90 Mail : bruno.martin@chu-dijon.fr Site web CHU : www.chu-dijon.fr

-----Message d'origine----- De : Jacob Brauer (JIRA) [mailto:issues@mirthcorp.com] Envoyé : mercredi 16 mars 2011 19:40 À : MARTIN Bruno Objet : [JIRA] Commented: (MIRTH-1778) Persistent blocking of Mirth JDBC postgres outgoing connector:jdbc Pool not open

[ http://www.mirthcorp.com/community/issues/browse/MIRTH-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626#action_14626 ]

Jacob Brauer commented on MIRTH-1778:

Have you reproduced the same error in Mirth Connect 2.x? Almost every library was upgraded for 2.0, in case the problem lies in one of those libraries. At this point I would recommend trying 2.1 RC1.

-- This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators: http://www.mirthcorp.com/community/issues/secure/Administrators.jspa

For more information on JIRA, see: http://www.atlassian.com/software/jira

Imported Comment. Original Details: Author: bruno.martin@chu-dijon.fr Created: 2011-03-17T04:32:35.000-0700

rbeckman-nextgen commented 5 years ago

Are you still experiencing this issue with the latest release?

Imported Comment. Original Details: Author: jacobb Created: 2011-06-09T14:14:42.000-0700

rbeckman-nextgen commented 5 years ago

Unfortunately, the problem remains (Mirth 2.1 lan ->jdbc->DMZ->8.3.9 postgres database/ intel Suse Linux SLES 11). The problem seems to come from the JDBC outbound connector in "drag & drop" mode (not javascript sql mode for JDBC connector), because the JDBC connection is never closed by Mirth, while the channel is programmed only once per day for this stream. (checked with pgadmin III: Tools-> server status). As this connection to the database goes through our firewall which configuration is regularly updated. The connection is probably set in an inconsistent state by the firewall when it takes too long (an entire day here).

We found a workaround which involves using the javascript mode for the jdbc outbound connector. In this case, the connection to the database is effectively cut off immediately after a database transfer, so the anomaly does not occur.

=> One question though, is it normal (or willing) that JDBC connector does not close the connection, in "drag and drop" sql mode while it does in JDBC connector javascript mode ? (idem for Mirth 1.8.2 as Mirth 2.1.1)

Imported Comment. Original Details: Author: bruno.martin@chu-dijon.fr Created: 2011-06-10T01:00:14.000-0700