[CONJ-1033] v2.7.5 breaks backwards compatibility when used against Aurora MySQL Created: 2022-12-13  Updated: 2023-02-01

Status: Open
Project: MariaDB Connector/J
Component/s: None
Affects Version/s: 2.7.5, 2.7.6, 2.7.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Julian Bui Assignee: Diego Dupin
Resolution: Unresolved Votes: 0
Labels: None
Environment:

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

 Comments   
Comment by Vladislav Vaintroub [ 2022-12-13 ]

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?

Comment by Julian Bui [ 2022-12-13 ]

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).

Comment by Diego Dupin [ 2022-12-15 ]

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.

Comment by Julian Bui [ 2022-12-16 ]

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?

Comment by Diego Dupin [ 2022-12-19 ]

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.

Comment by Julian Bui [ 2023-02-01 ]

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?

Generated at Thu Feb 08 03:20:07 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.