Bad handshake while connecting with jdbc:mysql:thin://<host>:<port>/

[Elena Stepanova]

The problem was initially reported in Tungsten replicator backtracking system as http://code.google.com/p/tungsten-replicator/issues/detail?id=256. It says that Tungsten fails while asking for a binlog dump.

From what I see after installing Tungsten and running connection tests with it, the problem is not related to binlog dump.

Tungsten uses two kinds of url-s to connect to the database: usually it connects as
"jdbc:mysql:thin://<host>:<port>/<schema>?createDB=true",
but sometimes as
"jdbc:mysql:thin://<host>:<port>/".
 The latter fails on 5.2.8 and higher (and on 5.3, too), with the "bad handshake" error. On 5.2.7 both lines work fine. 5.1.60 looks okay too.

My wild guess is that it's somehow related to client plugin authentication, namely to a corner(?) case when server on some reason thinks the client is using plugin authentication while in fact it does not. It's pure speculation though.

I've attached a simple Java test case that uses the same classes as Tungsten for database connection, but does not do anything else. The tarball contains everything (apart from java itself) needed to run the test case -- the compiled test, libraries and the runner. Extract the archive, cd into the 'test' folder, launch ./run (you need to have your DB server already running). If you are using a port other than 3306, edit the 'run' file to add -Dport=<port> property to run the java class.
The test code is below.

Test case:

import com.continuent.tungsten.replicator.database.DatabaseFactory;
import com.continuent.tungsten.replicator.database.Database;
import java.sql.SQLException;

public class test
{
   public static void main (String argv[])
   {
      try
      {
         String port = System.getProperty("port");
         if (port == null) {
            port="3306";
         }
         String conLine1 = "jdbc:mysql:thin://localhost:"+port+"/tungsten_logos?createDB=true";
         String conLine2 = "jdbc:mysql:thin://localhost:"+port+"/";
         System.out.println("\nConnecting with " + conLine1 + "\n");
         System.out.println("(Do not pay attention to log4j complaints)");
         Database conn1 = DatabaseFactory.createDatabase(conLine1, "root", "");
         conn1.connect();
         System.out.println("\nLooks OK...");
         System.out.println("Now connecting with " + conLine2);
         Database conn2 = DatabaseFactory.createDatabase(conLine2,"root","");
         try {
            conn2.connect();
         }
         catch (SQLException e)
         {
                 System.out.println("This is the error we are looking for:");
                 System.out.println(e + "\n");
         }
      }
      catch (Exception e)
      {
         System.out.println("Problems..." + e + "\n");
      }
   }
}

[Elena Stepanova (elenst)]

Further investigation has shown that the problem does not occur with an up-to-date version of drizzle-jdbc. Tungsten packages still contain drizzle-jdbc-0.91-SNAPSHOT, while a recent version is 1.1.

According to serg's analysis, the old version of drizzle-jdbc was incorrectly setting CLIENT_PLUGIN_AUTH bit in the handshake packet, without actually supporting pluggable auth. It has been fixed in 1.1.

If I simply replace the jar by the newer one, the handshake goes normally, both with the simplified test case above and with the actual Tungsten startup. Tungsten proceeds to the next step, where it does fail, not due to a handshake problem, but with UnsupportedEncodingException, apparently due to incompatibility with the new version of drizzle-jdbc.

[Elena Stepanova (elenst)]

So, although older MariaDB versions accepted the malformed packet and the newer don't, the root cause is the invalid setting on the client side, which has been fixed already. Thus, I'm closing the bug.