MySQL Connector/J 5.1.41 has been released

[Gipson Pulla]

Dear MySQL Users,

MySQL Connector/J 5.1.41, a maintenance release of the production 5.1
branch has been released. Connector/J is the Type-IV pure-Java JDBC
driver for MySQL.

Version 5.1.41 is suitable for use with many MySQL server versions,
including 4.1, 5.0, 5.1, 5.4 and 5.5.

MySQL Connector Java is available in source and binary form from the
Connector/J download pages at
http://dev.mysql.com/downloads/connector/j/5.1.html
and mirror sites as well as Maven-2 repositories.

MySQL Connector Java (Commercial) is already available for download on the
My Oracle Support (MOS) website. This release will be available on eDelivery
(OSDC) in next month's upload cycle.

As always, we recommend that you check the "CHANGES" file in the
download archive to be aware of changes in behavior that might affect
your application.

MySQL Connector/J 5.1.41 includes the following general bug fixes and
improvements, also available in more detail on
http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-41.html

Changes in MySQL Connector/J 5.1.41 (2017-02-28)

   Version 5.1.41 is a maintenance release of the production 5.1
   branch. It is suitable for use with MySQL server versions
   5.5, 5.6, and 5.7. It supports the Java Database Connectivity
   (JDBC) 4.2 API.

   Bugs Fixed

     * Connections failed with MySQLSyntaxErrorException:
       Unknown character set when
       connectionCollation=ISO-8859-13. This was due to a wrong
       logic in Connector/J's internal charset mapping, which
       has now been fixed. (Bug #25504578)

     * When loading classes through some external class loaders,
       com.mysql.jdbc.Util threw an NoClassDefFoundError. This
       was caused by Class.getPackage() returning null when some
       external class loaders were used. This fix replaces those
       calls of Class.getPackage() with calls of the new method
       Class.getName(), which return package names that are
       extracted from the fully-qualified class names. (Bug
       #25048543, Bug #83052)

     * In the manifest for the Connector/J JAR file, the
       Import-Package directive specified version numbers for
       the javax.net.ssl package. The specification was
       unnecessary, and it caused the configuration of an SSL
       connection to a MySQL server to fail in an OSGi
       environment. The version requirement has now been
       removed. (Bug #24942672, Bug #82826)

     * In a Fabric setup, when multiple threads required to have
       hashes computed, an ArrayIndexOutOfBoundsException might
       be thrown from inside HashShardMapping. This fix prevents
       the issue by having
       HashShardMapping.getShardIndexForKey() synchronized. (Bug
       #24289730, Bug #82203)

     * When the configuration property cacheResultSetMetadata
       was set to true, a ping query using a PreparedStatement
       failed with a NullPointerException. This fix moves the
       ping query to an earlier stage of the statement
       execution, which prevents the exception. (Bug #23535001,
       Bug #81706)

     * The setFabricShardTable() method failed to parse
       qualified table names (in the format of
       database_name.table_name), which causes SQLExceptions to
       be thrown. (Bug #23264511, Bug #81108)

     * A race condition occurred when a call of
       Connection.setNetworkTimeout() was followed closely by a
       call of Connection.close(), and a NullPointerException
       might result if the connection was closed before the
       executor supplied to setNetworkTimeout() was able to set
       the timeout, as the executor would run into a null
       mysqlConnection object. This fix removed the race
       condition. (Bug #21181249, Bug #75615)

     * With the connection properties
       cacheServerConfiguration=true and
       elideSetAutoCommits=true, any new connection to the
       server obtained after the first connection was
       established had the variable autoCommit equaled false,
       even if the value of the variable was true on the server.
       That was because the value of autoCommit was not properly
       initialized when a new connection was established, and
       this fix corrects that.
       Also, since release 5.1.41, the functionality of the
       property elideSetAutoCommits has been disabled due to
       Bug# 66884. Any value given for the property is now
       ignored by Connector/J. (Bug #17756825, Bug #70785)

     * When using Tomcat and a web application that utilized
       Connector/J was down, Tomcat was unable to stop the
       AbandonedConnectionCleanupThread started internally by
       Connector/J, leading to multiple instances of the thread
       when the web application was restarted; or, Tomcat was
       able to stop the thread but unable to restart it on
       reload of the web application. Different combinations of
       Tomcat's default settings, usage of Tomcat's
       ServletContextListener feature, and locations of the
       Connector/J jar could result in the undesired behaviors,
       as well as warning messages in the Tomcat error log
       saying it was unable to stop the thread and a memory leak
       was likely.
       The implementation of AbandonedConnectionCleanupThread
       has now been improved, so that there are now four ways
       for developers to deal with the situation:

          + When the default Tomcat configuration is used and
            the Connector/J jar is put into a local library
            directory, the new built-in application detector in
            Connector/J now detects the stopping of the web
            application within 5 seconds and kills
            AbandonedConnectionCleanupThread. Any unnecessary
            warnings about the thread being unstoppable are also
            avoided. If the Connector/J jar is put into a global
            library directory, the thread is left running until
            the JVM is unloaded.

          + When Tomcat's context is configured with the
            attribute clearReferencesStopThreads="true", Tomcat
            is going to stop all spawned threads when the
            application stops unless Connector/J is being shared
            with other web applications, in which case
            Connector/J is now protected against an
            inappropriate stop by Tomcat; the warning about the
            non-stoppable thread is still issued into Tomcat's
            error log.

          + When a ServletContextListener is implemented within
            each web application that calls
            AbandonedConnectionCleanupThread.checkedShutdown()
            on context destruction, Connector/J now, again,
            skips this operation if the driver is potentially
            shared with other applications. No warning about the
            thread being unstoppable is issued to Tomcat's error
            log in this case.

          + When
            AbandonedConnectionCleanupThread.uncheckedShutdown()
            is called, the AbandonedConnectionCleanupThread is
            closed even if Connector/J is shared with other
            applications. However, it may not be possible to
            restart the thread afterwards.
       (Bug #17035755, Bug #69526)
       References: See also: Bug #14570236, Bug #16443387.

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla