Docker lucee/lucee:5.3-nginx can not connector to MySQL

I’m running the latest Lucee Docker image : docker run -p 80:80 -v/tmp/:/var/www lucee/lucee:5.3-nginx

In /tmp I have
Application.cfc

component{	
this.datasources["evdb.smecoms"] = { class: 'com.mysql.cj.jdbc.Driver' , connectionString: 'jdbc:mysql://something.eu-west-number.rds.amazonaws.com:3306/smecoms?useUnicode=true&characterEncoding=UTF-8&useLegacyDatetimeCode=true', username: 'someone' , password: "password" };

this.datasource='evdb.smecoms';
	
}

and index.cfm

<cfscript>
dbinfo type="columns" table="partner" name="test" ;
</cfscript>

The machine I’m running this on, and the mysql tools inside the container (once apt install’d) can all connect fine, at least as far as a username/password error.

However, Lucee errors with

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.

This is a box standard Amazon RDS MySQL server, and everything else on my machine, including Lucee 5.2.x containers, can connect fine.

I’m stuck, out of ideas, and frustrated that what should be so easy has already taken me a while to get to this stage off.

What on earth could be wrong ?

The lucee/lucee:5.3.8.201-SNAPSHOT-nginx tag (which should match the latest release I think) is exactly the same behaviour.

Surely I’m missing something that’s now required to do ?!?

If I add &useSSL=false to the JDBC URL then I get a username/password failure as expected.

So something is wrong/different with how the updated Tomcat/Java/Lucee work together…

There are some oddities I can observe in Wireshark packet traces (yes, it’s that bad) - working older Lucee does a TLSv1.1 “client hello” right after RDS sends the server greeting and login request, newer not working Lucee does a TCP FIN/ACK to close the connection right after sending login request, and the server responds with SSL data which looks mangled.

If I add &enabledTLSProtocols=TLSv1.2 to the JDBC string connections work.

As Lucee 5.2.x to 5.3.x needs every single datasource in every app we have updating because of the change in class name, this isn’t too big a deal, but I’d love to find a way to make the defaults (TLScsomething else ?) work, or change the defaults to TLSv1.2

Oracle’s docs are, well, hard going…

Weird. I would think it would negotiate from highest to lowest.
You could try to limit the server to TLSv1.3 and v1.2. Everything I read is it should try 1.3 first and go down. There was a note in the Connector/J docs that some older MySQL 5.6 and 5.7 servers don’t do v1.2 by default.

https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html

5.3.6.61 does not exhibit this issue, so it’s something changed between that and 5.3.8.201 Lucee images. Might not even be Lucee’s fault e.g. OpenSSL or the JVM could have changed something…

Some further testing shows, the 5.3.8.150 snapshot works but the next at 5.3.8.151 fails

@justincarter

Hmm… The Docker builds don’t do anything specific to database drivers so in general there shouldn’t be any difference between Docker, or Lucee Express, or a Lucee Installer if all of them use the same Lucee version number – the source lucee.jar file is the same. That means if you grab Lucee Express 5.3.8.150-SNAPSHOT and 5.3.8.151-SNAPSHOT you might be able to compare between those two to see if the same problem exists on your system. If one works and the other doesn’t then it’s a Lucee issue, and if they both fail or both succeed then it could be a change of version of something in the Docker image like you suggest.

Since 5.3.8.150 is 7 months old it would have been using the base Tomcat image with whatever version of Java it came with at the time. It would also seem like it should have been fixed by now though, the latest Lucee builds use the latest Tomcat base images so a bug like that shouldn’t hang around for long if Java was the issue?

1 Like

odd, the only changes between those two snapshots are related to static components