PHINMS 3.0 Error
Bruce Riddle
SENDER LOG
Thread-87|03/12|08:50:43|C:\PHINMS30/shared/sendermultiblockDir// cleaner stopped!|
http-nio-5088-exec-6|03/12|08:50:44|Warning: DatabaseInfo:useridentifier unspecified|
http-nio-5088-exec-6|03/12|08:50:44|Warning: DatabaseInfo:passwordidentifier unspecified|
http-nio-5088-exec-6|03/12|08:50:44|Processing folderMap: C:\PHINMS30/config/sender/foldermap.xml|
http-nio-5088-exec-6|03/12|08:50:44|Error, decryption keystore: C:\PHINMS30/security/sender/cert.pfx not found|
http-nio-5088-exec-6|03/12|08:50:44|Error opening decryption keystore: C:\PHINMS30/security/sender/cert.pfx|
http-nio-5088-exec-6|03/12|08:50:44|Warning: keystore C:\PHINMS30/security/sender/cert.pfx does not exist|
http-nio-5088-exec-6|03/12|08:50:44|=== Spawning queue 0 ============|
Thread-90|03/12|08:50:44|Initializing requeue cachepath from C:\PHINMS30/\shared\requeueCache|
Thread-90|03/12|08:50:44|Spawning multi database poller 1...|
Thread-91|03/12|08:50:44|Connection established|
Thread-91|03/12|08:50:44|Waiting for records ...|
http-nio-5088-exec-6|03/12|08:50:44|Error creating connection pool for dbid: RNR|
http-nio-5088-exec-6|03/12|08:50:44||
I also errors in other logs that I am told to ignore (running 32 bit library in 64 bit environment, etc.) .
Schneider, Edward (MNIT)
I am willing to venture a possibly less-than-informed opinion on part of this. First, within SQL Server, check the configured size for the maximum number of connections, then the actual number of connections being made when the error you're experiencing occurs. For a generally analogous set of procedures, see https://dba.stackexchange.com/questions/51219/max-connection-pool-capped-at-100. You may have to set the number of connections you need in the connection string (within the PHINMS sender.xml and receiver.xml files tagged values for <databaseUrl>, or via the PHINMS console settings for those tags), as discussed in the link. (And, by the way, is the related database in SQL Server actually called RNR? Would there have been some change in that, as compared with your PHINMS 2.8 SQL Server backend setup? Are your SQL Server login credentials up to date?)
As to the Tomcat-Native Library, the Tomcat 8.5 installed with PHINMS v. 3.0 has several alternative capabilities, depending on the configuration values in play in <PHINMS_installation_folder>\appserver\conf\server.xml,
for how SSL/TLS works in the absence of a front-end proxying application (like IIS). On the one hand, the default PHINMS 3.0 configuration relies on the Java Secure Sockets extension (JSSE). Recent versions of JSSE can work with the latest Tomcat Native
Libraries (version 1.2.6 minimum, based on your error message). These permit fast, high-volume processing with the Java NIO connector, and can implicitly invoke OpenSSL techniques. If your Tomcat native library version is earlier, NIO processing is considerably
slower--although if your typical throughput is modest, that might not be significant; and there would also be no invoking of OpenSSL techniques. The "traditional" (?) alternative was to use an APR [Apache Portable Runtime] configuration with OpenSSL (OpenSSL
is not provided with PHINMS itself). If your APR configurations are commented out (<!-- to start with and --> to end the comment) in the server.xml, then they aren't related to your problem with the library. --The other side of this issue is that making
a choice between the JSSE method and the APR method can affect the cipher suites available for encryption. As PHINMS v. 3.0 relies on Java 7, the more sophisticated ciphers available lag behind current best choices--in particular they were limited by relying--at
least in part--on CBC [chain -blocking] components, which have some potentially exploitable vulnerabilities. To the extent that the recent Tomcat Native Library permits implicit JSSE use of OpenSSL capabilities, the available ciphers MIGHT be expanded--but
I have yet to test that proposition. (Note that if your traffic is supplementally encrypted at the message, as well as the SSL/TLS, levels, with different certificates at the respective levels, there may be less concern about any SSL-level encryption vulnerabilities.)
Minnesota IT Services | Partnering with Minnesota Department of Health
625 North Robert St.
P.O. Box 64975
St. Paul, MN 55164-0975
O: 651-201-4047
Information Technology for Minnesota Government | mn.gov/mnit
Sent: Monday, March 12, 2018 2:13:18 PM
To: PHINMS User Community
Subject: PHINMS 3.0 Error
---
You received this message because you are subscribed to the Google Groups "PHINMS User Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phinms+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Schneider, Edward (MNIT)
One other thing. If your SQL Server and your PHINMS aren't behind the same firewall, have you checked your firewall access rules for the traffic between them, both inbound and outbound? (Also, if your SQL Server host--or
for that matter, your PHINMS host--is running the Windows internal firewall, earlier experience with PHINMS 2.9 on Windows suggests it's quite difficult to get the internal firewall rules adjusted to permit necessary inbound and outbound traffic to PHINMS.
Probably better the internal Windows firewall(s) should be turned off entirely, and rely on a properly-configured external firewall or firewalls.)
Minnesota IT Services | Partnering with Minnesota Department of Health
625 North Robert St.
P.O. Box 64975
St. Paul, MN 55164-0975
O: 651-201-4047
Information Technology for Minnesota Government | mn.gov/mnit
Sent: Monday, March 12, 2018 2:13:18 PM
To: PHINMS User Community
Subject: PHINMS 3.0 Error
Bruce Riddle
To unsubscribe from this group and stop receiving emails from it, send an email to phinms+unsubscribe@googlegroups.com.
--
---
You received this message because you are subscribed to the Google Groups "PHINMS User Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phinms+unsubscribe@googlegroups.com.
Bruce Riddle
Preacher Man
Well said Edward! If I may (ahem) editorialize a bit myself...
For those using "enterprise" backends for PHINMS (e.g. Oracle, MSSQL, etc) good communications with your dB admin is a must. There are just too many variables that can mess up PHINMS dB connections. Besides firewall issues and allowed open connections, there may also be re-connection restrictions, timeouts, and of course permissions that dB admins may "tweak" for security reasons and cause issue.
One PHINMS client I managed used a backend that was on a lossy/slow network. PHINMS sender requests could wait up to 10 minutes for a receiver reply. Re-connections would fail and after 5 tries the backend would lock out the account. Then one had to put in an issue with the dB admin and wait (sometimes days) for the account to be re-enabled. The connection policies for the dB were tailored for interactive users.
As for Tomcat, I always relied on the APR implementations. JSSE has a history of bugs and missing features. Amazingly, I could code an OpenSSL connection in 'C' with fewer lines of code than an equivalent JSSE connection in Java. Things may be better now as I have been out of that game for a few years. Even so, updates to JSSE ciphers are not going to be much help until the PHINMS xml (payload) encryption classes are upgraded to use them, and I wouldn't hold my breath on that (if you peak inside an xml encrypted payload, you will probably see it is still using RSA-1 over Triple DES for certificate based encryption).
In any event, if you are using a proxy with PHINMS on a private network, the (big bad internet) SSL negotiations will be handled by the proxy and not a real issue - at least for a receiver. A "naked" PHINMS sender could use help there though, which is where 3.0 should be a real improvement. Nice to know CDC hasn't completely given up on PHINMS yet.
Ya'll keep the faith.
Tom
Sent: Monday, March 12, 2018 3:24 PM
To: PHINMS User Community
Subject: Re: PHINMS 3.0 Error