[MXS-1634] clients timeout on net_read_timeout, server thread is in sleep state Created: 2018-01-29  Updated: 2019-02-04  Resolved: 2019-02-04

Status: Closed
Project: MariaDB MaxScale
Component/s: N/A
Affects Version/s: 2.1.13
Fix Version/s: 2.3.3

Type: Bug Priority: Major
Reporter: Maikel Punie Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Attachments: File maxscale.cnf     File table.sql    
Sprint: MXS-SPRINT-51, MXS-SPRINT-53

 Description   

We have a situation where we the clients timeout, during the timeout the connection on the server is in the sleep state.

It looks as the server replied to maxscale, but maxscale is not forwarding the reply to the client.

After some debugging we noticed the following:

  • the server never replies to the sql command (traced via pcap)
  • created a new db with a new table that only has the 2 affected columns, and even with this we can reproduce it
  • the issue seems dependent on the query length
  • 2800 = pass
  • 2892 = fail
  • 8187 = fail
  • 4340 = fail

 Comments   
Comment by markus makela [ 2018-03-06 ]

If you increase net_read_timeout, does it work?

Comment by Maikel Punie [ 2018-03-06 ]

it seems to correlate, the time it takes is dependant on the net_read_timeout

Comment by markus makela [ 2018-03-06 ]

Does that mean that increasing the timeout requires a longer query in order to see the failure? If so, this might be an actual issue with a timeout.

Comment by Maikel Punie [ 2018-03-06 ]

no it just takes longer before the error is returned,
it can be reproduced with the same querry

Comment by markus makela [ 2018-03-06 ]

OK, then it does appear that MaxScale doesn't return the result. I misunderstood what the original problem was. We'll continue investigating as we haven't been able to reproduce it.

Comment by markus makela [ 2018-03-12 ]

Which connector are you using to connect to MaxScale and are you using prepared statements?

Comment by Maikel Punie [ 2018-03-12 ]

this has no prepare statements

this is a python tool that runs the querrys.

There we use the _mysql module for connecting.

Comment by markus makela [ 2018-03-12 ]

Is that the MySQL Python connector?

Comment by Maikel Punie [ 2018-03-12 ]

its this one

http://mysql-python.sourceforge.net/MySQLdb.html

Comment by markus makela [ 2018-03-12 ]

OK, thanks. I've been testing with PyMySQL and I've had no problems.

Comment by markus makela [ 2018-03-19 ]

Can you reproduce this with MaxScale 2.2?

Comment by Maikel Punie [ 2018-03-20 ]

yep, we are running MaxScale 2.2.2 and we still see this

Comment by markus makela [ 2018-03-20 ]

OK, thanks for confirming.

Comment by markus makela [ 2018-11-27 ]

Please try this with the latest version of 2.2.

Comment by Maikel Punie [ 2019-02-04 ]

we do not see this with maxscale 2.3

Comment by markus makela [ 2019-02-04 ]

Given that we haven't been able to reproduce this on our side, I think we can close this as fixed in 2.3. Let us know if you see something similar in 2.3 so that we can reopen this.

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