Uploaded image for project: 'MariaDB Connector/J'
  1. MariaDB Connector/J
  2. CONJ-1033

v2.7.5 breaks backwards compatibility when used against Aurora MySQL

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 2.7.5, 2.7.6, 2.7.7
    • None
    • None
    • None
    • mac os

    Description

      With 2.7.5 and onwards, mariadb driver usage against aurora mysql instances will not work. I realize there are other bugs like this filed against lower versions, but I can confirm the problem does not exist in 2.7.2 and 2.7.4 for instance.

      I realize that I can add `?usePipelineAuth=false` and it will workaround the issue but the point is that this is a backwards compatibility breaking change. I am wondering if you have considered reverting the backwards compatibility breaking change for the v2.7.X line. Keeping that change makes it so anyone wanting security fixes will have their workflows broken.

      Probably related to CONJ-895

      Repro:

      1) write an application with a valid aurora mysql instance credentials set for userName and password and provide a "jdbc:mariadb://<aurorahost>:3306/database" for jdbcUrl

      try (Connection conn = DriverManager.getConnection(jdbcUrl, userName, password))

      { // anything }

      2) Provide maria jdbc driver v2.7.5
      3) Execute the application

      Expected: Successful connection
      Actual: Caused by: java.sql.SQLNonTransientConnectionException: Could not connect to address=(host=<MYHOSTNAME>)(port=3306)(type=master) : (conn=34916) could not load system variables

      4) Replace the v2.7.5 driver with 2.7.4 and get a successful connection

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          wlad Vladislav Vaintroub added a comment - - edited

          julianbui Thing is , Aurora has had that bug for ages, and it is their responsibility to fix it. A server .does not discard client input, but Aurora does it. Did you try to report this for Aurora, so that the driver developers do not all have to workaround their broken idea of how client and server can communicate?

          wlad Vladislav Vaintroub added a comment - - edited julianbui Thing is , Aurora has had that bug for ages, and it is their responsibility to fix it. A server .does not discard client input, but Aurora does it. Did you try to report this for Aurora , so that the driver developers do not all have to workaround their broken idea of how client and server can communicate?
          julianbui Julian Bui added a comment -

          I understand that Aurora has had this issue for a long time. However, in my opinion, the maria jdbc driver maintainers should not be making large backwards compatibility breaking changes in a patch version. That type of change is much more acceptable for a major version (e.g., upgrade from maria jdbc v2 to v3). As far as I'm aware, you did not need to make this change when you did.

          I would also like to note that the aurora notice on https://mariadb.com/kb/en/about-mariadb-connector-j/ seems to convey that v3 would not support aurora but v2 does and would for 5 years, if I'm reading that correctly. 

          driver 3.0 is a complete rewrite of the connector. Specific support for aurora has not been implemented in 3.0, since it relies on pipelining. Aurora is not compatible with pipelining. Issues for Aurora were piling up without the community proposing any PR for them and without access for us to test those modifications. (2.x version has a 5 years support).

          julianbui Julian Bui added a comment - I understand that Aurora has had this issue for a long time. However, in my opinion, the maria jdbc driver maintainers should not be making large backwards compatibility breaking changes in a patch version. That type of change is much more acceptable for a major version (e.g., upgrade from maria jdbc v2 to v3). As far as I'm aware, you did not need to make this change when you did. I would also like to note that the aurora notice on https://mariadb.com/kb/en/about-mariadb-connector-j/ seems to convey that v3 would not support aurora but v2 does and would for 5 years, if I'm reading that correctly. driver 3.0 is a complete rewrite of the connector. Specific support for aurora has not been implemented in 3.0 , since it relies on pipelining. Aurora is not compatible with pipelining. Issues for Aurora were piling up without the community proposing any PR for them and without access for us to test those modifications. ( 2 .x version has a 5 years support).
          diego dupin Diego Dupin added a comment -

          At some point, Amazon did help for using aurora. Now we don't have even access to any test aurora instances, and community has never help with any aurora issues.

          So any changes relative to aurora cannot be verified ...
          (i'm not even speaking of doing work for Amazon, because of an issue known for more than 7 years, because they doesn't seem to support their own proxy)

          Now comes issue CONJ-895 that makes all AWS instances not using pipelining (so slower performance) for - it seems - no reasons.
          I agree that this could have been in a 2.8 release, if we could have tested it. This was only considered as a bug fix.

          Only solution then is to use "?usePipelineAuth=false&useBatchMultiSend=false&disablePipeline=false", because there doesn't seem to be any way we can rely specific aurora url.

          diego dupin Diego Dupin added a comment - At some point, Amazon did help for using aurora. Now we don't have even access to any test aurora instances, and community has never help with any aurora issues. So any changes relative to aurora cannot be verified ... (i'm not even speaking of doing work for Amazon, because of an issue known for more than 7 years, because they doesn't seem to support their own proxy) Now comes issue CONJ-895 that makes all AWS instances not using pipelining (so slower performance) for - it seems - no reasons. I agree that this could have been in a 2.8 release, if we could have tested it. This was only considered as a bug fix. Only solution then is to use "?usePipelineAuth=false&useBatchMultiSend=false&disablePipeline=false", because there doesn't seem to be any way we can rely specific aurora url.
          julianbui Julian Bui added a comment -

          Re: CONJ-895, I understand the predicament with the URLs. I also wanted to use the URL to programmatically set the compatible options when used with Aurora MySQL but have no way to know which URLs are Aurora MySQL.

          Can you help me understand CONJ-895? I understand that the URL alone doesn't tell us if the the instance is RDS Aurora MySQL vs. RDS MySQL vs. RDS Mariadb. Which RDS database types will have the faulty proxy? is it just the RDS Aurora MySQL type and not the others?

          julianbui Julian Bui added a comment - Re: CONJ-895 , I understand the predicament with the URLs. I also wanted to use the URL to programmatically set the compatible options when used with Aurora MySQL but have no way to know which URLs are Aurora MySQL. Can you help me understand CONJ-895 ? I understand that the URL alone doesn't tell us if the the instance is RDS Aurora MySQL vs. RDS MySQL vs. RDS Mariadb. Which RDS database types will have the faulty proxy? is it just the RDS Aurora MySQL type and not the others?
          diego dupin Diego Dupin added a comment -

          Only aurora has the faulty proxy, other doesn't have any proxy, so doesn't have the issue.

          CONJ-895 was initially done to permit connecting to aurora host directy with using "jdbc:mariadb:aurora" prefix, just disabling pipelining options.
          That's why disabling pipelining option in url will do exaclty the same thing, aurora beeing compatible with MariaDB/MySQL protocol.

          diego dupin Diego Dupin added a comment - Only aurora has the faulty proxy, other doesn't have any proxy, so doesn't have the issue. CONJ-895 was initially done to permit connecting to aurora host directy with using "jdbc:mariadb:aurora" prefix, just disabling pipelining options. That's why disabling pipelining option in url will do exaclty the same thing, aurora beeing compatible with MariaDB/MySQL protocol.
          julianbui Julian Bui added a comment -

          Diego, I'd like to appeal to you one more time. We have so many customers recently hitting locking issues (https://jira.mariadb.org/browse/CONJ-863 and https://jira.mariadb.org/browse/CONJ-983) and we canot fix them unless we go to 2.7.6 which breaks backward compatibility with Aurora MySQL instances. Maria jdbc documentation states that you would be supporting aurora mysql instances in 2.X. 

          ...Aurora is not compatible with pipelining. Issues for Aurora were piling up without the community proposing any PR for them and without access for us to test those modifications. (2.x version has a 5 years support).

          Is there any way to fix the backwards incompatibility introduced in 2.7.5?

          julianbui Julian Bui added a comment - Diego, I'd like to appeal to you one more time. We have so many customers recently hitting locking issues ( https://jira.mariadb.org/browse/CONJ-863 and https://jira.mariadb.org/browse/CONJ-983 ) and we canot fix them unless we go to 2.7.6 which breaks backward compatibility with Aurora MySQL instances. Maria jdbc documentation states that you would be supporting aurora mysql instances in 2.X. ...Aurora is not compatible with pipelining. Issues for Aurora were piling up without the community proposing any PR for them and without access for us to test those modifications. ( 2 .x version has a 5 years support). Is there any way to fix the backwards incompatibility introduced in 2.7.5?

          People

            diego dupin Diego Dupin
            julianbui Julian Bui
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.