I understand the overarching cause here: Lucee cannot connect to the database.
But other programs on this machine can.
I’m running the “Express” 5.3.8.206 version for development on my Zorin Linux OS 16 laptop. It’s been wonderful, connecting to many AWS RDS flavors (like Postgres, MSSQL and MySQL).
I’ve also set up DBeaver 21.3.4 IDE for added SQL madness… on the same laptop
The problem pops up for my one Maria instance:
DBeaver can connect to it without issue. Any user, any DB.
Lucee cannot (“Communications link failure”), regardless of user or DB.
Because both of these examples are on the same laptop, network layer issues have pretty much been ruled out, right?
Maybe I need more than the admin UI to set this up; do you have any script or tag DSN suggestions - which introduce some needed parameters I’m not aware of?
Thanks for reading, and sorry for the almost-repetitive subject.
Which database driver Lucee extension are you using? MySQL or MariaDB?
Can you verify the datasource in your admin UI (i.e. ticking the box and clicking “Verify”)?
To try a scripted version, edit the datasource entry and scroll down to the bottom of the page where you’ll find a box titled “You can also set this in the Application.cfc as follows:”
The only options for DSNs in my Lucee Admin version are JTDS, Microsoft SQL Server, MySQL (selected), Other and PostgreSQL. *
From other threads here, it seems like Maria is supposed to mimic compatibility with MySQL.
This is the same setup that is used on other Linux/Lucee machines (like our production box), which also use different JDBC clients besides Lucee to do business.
But on my laptop, only Lucee throws the communications link failure. The other client (DBeaver) works fine - but it has a specific Maria option.
** * Is a special extension now required for Maria connections to work?**
Thanks for the reminder of the scripting option provided by the admin UI, my question was more along the lines of introducing settings that might not be available in the form (like “ValidateServerCertificate=no” or some such thing).
Can you test on the latest 5.3.9? Lucee had a super annoying bug in the error handling for JDBC connections that discarded the “caused by” portion of jdbc connection exceptions which contains the actual cause. Communication Failure is just a generic message for all failures. I sent a pull request to fix this and it’s part of 5.3.9. Troubleshooting any connection failure is pretty much impossible otherwise and I was floored Lucee had been doing this for so long.
Always nice to hear from you, Brad, although my preferred method is conference junkets. The high-level message did not change.
FWIW: Here’s the full dump after updating to 5.3.9.80-RC and restarting. Much like your write up, does this little item have significance?
negotiateSSLConnection
lucee.runtime.exp.NativeException: Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. at com.mysql.cj.jdbc.exceptions.SQLError.createCommunicationsException(SQLError.java:174) at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:64) at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:836) at com.mysql.cj.jdbc.ConnectionImpl.(ConnectionImpl.java:456) at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:246) at com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:197) at lucee.runtime.db.DataSourceSupport._getConnection(DataSourceSupport.java:135) at lucee.runtime.db.DataSourceSupport.getConnection(DataSourceSupport.java:103) at lucee.runtime.tag.Admin._doVerifyDatasource(Admin.java:2920) at lucee.runtime.tag.Admin.doUpdateDatasource(Admin.java:2696) at lucee.runtime.tag.Admin._doStartTag(Admin.java:741) at lucee.runtime.tag.Admin.doStartTag(Admin.java:355) at services_datasource_create_cfm1334$cf.call(/admin/services.datasource.create.cfm:88) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:1034) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:926) at lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:907) at services_datasource_cfm414$cf.call(/admin/services.datasource.cfm:108) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:1034) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:926) at lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:907) at web_cfm$cf.call(/admin/web.cfm:492) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:1034) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:926) at lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:907) at server_cfm$cf.call(/admin/server.cfm:2) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:1034) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:926) at lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java:217) at lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:44) at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2460) at lucee.runtime.PageContextImpl._execute(PageContextImpl.java:2450) at lucee.runtime.PageContextImpl.executeCFML(PageContextImpl.java:2421) at lucee.runtime.engine.Request.exe(Request.java:45) at lucee.runtime.engine.CFMLEngineImpl._service(CFMLEngineImpl.java:1194) at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:1140) at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(CFMLEngineWrapper.java:97) at lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:831) Caused by: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. … 60 more Caused by: com.mysql.cj.exceptions.CJCommunicationsException: Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480) at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:61) at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:105) at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:151) at com.mysql.cj.exceptions.ExceptionFactory.createCommunicationsException(ExceptionFactory.java:167) at com.mysql.cj.protocol.a.NativeProtocol.negotiateSSLConnection(NativeProtocol.java:338) at com.mysql.cj.protocol.a.NativeAuthenticationProvider.negotiateSSLConnection(NativeAuthenticationProvider.java:777) at com.mysql.cj.protocol.a.NativeAuthenticationProvider.proceedHandshakeWithPluggableAuthentication(NativeAuthenticationProvider.java:486) at com.mysql.cj.protocol.a.NativeAuthenticationProvider.connect(NativeAuthenticationProvider.java:202) at com.mysql.cj.protocol.a.NativeProtocol.connect(NativeProtocol.java:1340) at com.mysql.cj.NativeSession.connect(NativeSession.java:157) at com.mysql.cj.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:956) at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:826) … 57 more Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) at java.base/sun.security.ssl.HandshakeContext.(HandshakeContext.java:172) at java.base/sun.security.ssl.ClientHandshakeContext.(ClientHandshakeContext.java:98) at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:238) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:434) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:412) at com.mysql.cj.protocol.ExportControlled.performTlsHandshake(ExportControlled.java:336) at com.mysql.cj.protocol.StandardSocketFactory.performTlsHandshake(StandardSocketFactory.java:188) at com.mysql.cj.protocol.a.NativeSocketConnection.performTlsHandshake(NativeSocketConnection.java:99) at com.mysql.cj.protocol.a.NativeProtocol.negotiateSSLConnection(NativeProtocol.java:329) … 64 more
On the same laptop, with the same strings, DBeaver has no problem connecting.
However, it is using this driver instead:
If youze guys think it would be a valid next step, AND you feel it would not mess up any other conditions in our ultra-scientific debugging process ;-] would you suggest I try using this other driver, IAW the instructions here: https://lucee.daemonite.io/t/custom-jdbc-connections/7002
Here’s the error. It’s always the last “caused by” in the stack on these scenarios and it’s a java ssl configuration issue. You should be able to search for it on Pete Freitag’s blog for more info.
Alan, if it wasn’t clear to you from Brad’s comment, the issue seems to be about the jvm that you have Lucee running on. My guess is that it’s a version that’s a good bit older than the currently supported LTS versions, 11.0.14 or 1.8.0_321.
And yes, this would explain why it happens in Lucee and yet not from DBeaver or other tools running on the same machine–if those tools either are not based on Java (like Lucee and ACF are) or they might even embed their own more recent java version.
FWIW, I’ve done a blog post this frequent need to update the jvm (used by CF or Lucee) to solve problems of calling out of cfml via https/tls. I’ve also done one on the most recent Java updates, from January 2022, for 8, 11, and 17–the latter of which will be supported by upcoming updates to CF and Lucee. (See my point in that last post also about an important change in the jvm updates since April 2021, where calls out to servers not yet supporting tls 1.2 would be blocked by default–and how that can be changed if needed.)
Finally, as for how to go about changing the jvm used by Lucee, that depends on how you installed/deployed Lucee, and may depend also on how you install/configure Java. The topic has been discussed here, the docs, and elsewhere. I’ll leave it at that for now, if the info above is all you needed to get going.
And of course I’m open to corrections if anyone thinks I’ve misspoken on any points.
Man, I really appreciate you heavy-hitters coming out from your man caves to help me out. Or would that be “men caves”… “mans cave”?
Anywhooo…
Our shared DEV server at Viviotech:
Lucee 5.3.6.61 running on Linux (4.4.0-210-generic) 64bit under Java 1.8.0_201 (Oracle Corporation) 64bit. This instance has JDBC Type 4 Driver for the MySQL and MariaDB databases version 8.0.24. SUCCESS: The above machine was able to establish a Lucee datasource to AWS Maria db/user without a problem.
My localhost dev laptop:
Lucee 5.3.9.80-RC running on Linux (5.13.0-28-generic) 64bit under Java 16.0.1 (AdoptOpenJDK) 64bit. This instance also has JDBC Type 4 Driver for the MySQL and MariaDB databases version 8.0.24.
All of this from a lucee-express-5.3.8.206 archive downloaded only 69 days ago. FAILED: This laptop was unable to establish a Lucee datasource to the same AWS Maria db/user, while a different app on the laptop can.
(That’s DBeaver - a customized Eclipse that uses the driver noted earlier, and runs on OpenJDK 11)
I’m still tinkering with the connection here. I just wanted to add more info to the thread.
Alan, can you confirm how you are determining the Java version? I have seen people presume that what they see with a java -version command is what Lucee uses, but instead please confirm what you see shown in the Lucee admin itself.
And if you DO confirm that the 16.0.1 really is what is shown in Lucee, then I would point you again to the point I made about TLS 1.2. It may be that your MariaDB implementation does not yet support it (that would surprise me). Anyway, see my blog post for more on how you could change the JVM to allow it to talk to a server not yet supporting tls 1.2, Just saying it’s an easy change to make and see if it helps. But please do this after checking out the lucee-reported jvm version.
Thanks, Charlie - all the stats in my 2-14 reply were taken directly from the relative Lucee admin Server Overview pages.
I’m going to pursue this as a likely TLS version issue.
Progress.
Modifying the connection string to omit all SSL security, and the DSN finally works. This is not the optimal solution, so I’m still working on a SSL connection.
(Note that in the admin UI, neither option is selected, and is allowed like this.)
Thanks to the commit by @bdw429s for some concise error messaging now: “Cannot open file:/home/xxxx/lucee-express-5.3.8.206/lucee-server/context/security/cacerts [Keystore was tampered with, or password was incorrect]”
Not sure what password is being referred to here. My command uses “sudo” to presumably run Lucee’s startup.sh as root. I have not “tampered” with cacerts.
Seeing as this is just a localhost dev laptop, my first inclination was to just cdmod all the permissions in this unzipped Lucee stack to 777 (none), but that seems extreme. When using Nautilus (ie Explorer) to navigate to the /security/ folder, I am prompted for my password repeatedly. As Linux distros go, Zorin is pretty tightfisted with the root user. Maybe I missed an installation note?
But at least the issue’s cause is in view now. I’ll keep looking & tinkering. Thanks for the tips.
The default password of Lucee’s cacerts file is changeit though I’ve never seen that error before so I’m not sure why it can’t open it Did you by chance wholesale copy another cacerts file from elsewhere over the top of Lucee’s as part of your attempts to make this work. In doing so, you could have put a file in place with another password. I’d have to see the full stack to know what code exactly was attempting to open that file.
Did you by chance wholesale copy another cacerts file from elsewhere over the top of Lucee’s as part of your attempts to make this work. In doing so, you could have put a file in place with another password. I’d have to see the full stack to know what code exactly was attempting to open that file.