[MXS-306] User authentication fails when using a large number of users Created: 2015-08-12  Updated: 2018-02-08  Resolved: 2015-09-14

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 1.2.0
Fix Version/s: 1.2.1

Type: Bug Priority: Critical
Reporter: markus makela Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS 7
MySQL 5.6.21


Issue Links:
Relates
relates to MXS-271 Schemarouter and unknown databases Closed
relates to MXS-1657 Use authentication fails on backend s... Closed
relates to MXS-356 Connection timeouts for authenticatio... Closed

 Description   

When the database has a large number of users or a large number of grants, user authentication sometimes fails. Reducing the number of users reduces the frequency of authentication failures. This would suggest that there is an unsafe read being done when authenticating users.



 Comments   
Comment by markus makela [ 2015-08-14 ]

I reproduced this with about 300 users each with an average of 250 grants for for each of the users.

2015-08-14 13:37:16   Error : Loading users for service SchemaRouter Router encountered error: Lost connection to MySQL server during query.

This happens when the result set is read into MaxScale through the MySQL C API.

Comment by markus makela [ 2015-08-21 ]

A notable thing is the fact that the embedded library is used for this query.

Comment by Dipti Joshi (Inactive) [ 2015-08-23 ]

johan.wikman, markus makela Please diagnose further with gdb breakpoints.

Comment by Dipti Joshi (Inactive) [ 2015-08-23 ]

ratzpo Please get connector team to work with Johan, Markus to diagnose and find fix for this.

Comment by Johan Wikman [ 2015-08-28 ]

Problem confirmed to be present also without MaxScale.

Comment by Johan Wikman [ 2015-08-31 ]

Test program sent to Holyfoot who will invastigate the issue 31.8.

Comment by markus makela [ 2015-09-09 ]

This is related to MXS-356 and was fixed by allowing the configuration of the authentication timeouts.

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