[MXS-585] Intermittent connection failure with MaxScale 1.2/1.3 using MariaDB/J 1.3 Created: 2016-02-18  Updated: 2016-08-11  Resolved: 2016-03-18

Status: Closed
Project: MariaDB MaxScale
Component/s: mariadbclient
Affects Version/s: 1.3.0, 1.4.0
Fix Version/s: 1.4.1

Type: Bug Priority: Major
Reporter: Guillaume Lefranc Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Blocks
is blocked by CONJ-256 Intermittent connection failure with ... Closed
Problem/Incident
causes CONJ-256 Intermittent connection failure with ... Closed

 Description   

Environment:
3 nodes of MariaDB Galera Cluster
1.2.1 or 1.3 MaxScale default configuration with galera monitor, RW split and readconnroute

Test case with Simple python2 script (install jaydebeapi lib with pip first)

import jaydebeapi
 
for i in range(1,10000):
    conn = jaydebeapi.connect('org.mariadb.jdbc.Driver', ['jdbc:mariadb://192.168.99.100:4008/option_service', 'root', 'admin'],'../mariadb-java-client-1.3.4.jar',)
    curs = conn.cursor()
    curs.execute('select ' + str(i) + ';')
    data = curs.fetchall()
    for val in data:
        print val[0].value
    conn.close()

After some iterations:

1
...
430
Traceback (most recent call last):
  File "jdbc.py", line 4, in <module>
    conn = jaydebeapi.connect('org.mariadb.jdbc.Driver', ['jdbc:mariadb://192.168.50.104:4008/test', 'maxuser', 'maxpwd'],'mariadb-java-client-1.3.4.jar',)
  File "/usr/lib/python2.7/site-packages/jaydebeapi/__init__.py", line 359, in connect
    jconn = _jdbc_connect(jclassname, jars, libs, *driver_args)
  File "/usr/lib/python2.7/site-packages/jaydebeapi/__init__.py", line 183, in _jdbc_connect_jpype
    return jpype.java.sql.DriverManager.getConnection(*driver_args)
jpype._jexception.SQLInvalidAuthorizationSpecExceptionPyRaisable: java.sql.SQLInvalidAuthorizationSpecException: Could not connect: Access denied for user ''@'192.168.50.1' (using password: NO)
 



 Comments   
Comment by markus makela [ 2016-02-18 ]

This was caused by using the buffer length instead of the SQL packet in the authentication response length calculation.

Comment by markus makela [ 2016-03-18 ]

This has reappeared in 1.4.0.

Comment by markus makela [ 2016-03-18 ]

The reason for the regression is the assumption made by the client protocol. It assumed that the complete packet was read into contiguous memory.

Comment by markus makela [ 2016-03-18 ]

The authentication now always uses contiguous memory when reading the network packets.

Generated at Thu Feb 08 04:00:25 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.