Linux CentOS 6.8, MySQL 5.6.19, php 5.3.3

Can you upload the maxscale.cnf and the error logs, both with all the sensitive information removed?

Also, if possible, please give an example set of SQL commands that causes this problem.

Uploaded maxscale.cnf and the max scale-logfile with info and debug enabled.
Please let me know if you need any other logfiles.

Also, uploaded a tcpdump-file containing two tcp-streams, one for webserver <> maxscale, and the other for maxscale <> mysql-server at the same time. This clearly shows the client getting the "#HY000"-error, even though the mysql-server responds correctly.

The statements where we see the problem is prepared statement-calls, like
"SELECT id FROM phpsessions WHERE userid = ? AND session_expires >= ? LIMIT 1"

I've been looking at the TCP dump and it does seem like the client on port 27313 is executing a prepared statement while MaxScale is still streaming a resultset back to the client. That in itself is not in any way wrong or unexpected but it might be a clue as to why it might not work.

What sort of a connector are you using?

The setup when the trace was taken:
web-portal (using PHP 5.3.3 without connection pooling) <- unix socket -> MaxScale 2.0.3
<- tcp > MaxScale 2.0.3 < tcp -> MySQL 5.6 19

So, the MaxScale installed on the web-server is used to pool connections towards the second MaxScale, which is used to be able to easy switch primary database backend server.

We have tried to exclude either of the MaxScale-instances, but without any reduction in the frequency of session disconnects.

One thing that would be good to rule out is the use of persistent connections. If you remove both the persistpoolmax and persistmaxtime parameters from all servers, do the disconnections still happen?

Removed persistpoolmax and persistmaxtime from both instances, and the problem disappeared.
Tried to enable again on one of the instances, and the problem reappeared almost instantly.
So it seems like this is caused by the connection pooling...

I can confirm that this is caused by the persistent connections. This only happens with the 2.0 version of MaxScale and the upcoming 2.1 version of MaxScale has fixed this. I'll investigate why if fails with 2.0 and if a fix for the 2.0 version can be created.

I've managed to pinpoint the problem to the use of prepared statements with persistent connections. With normal queries, the persistent connections work. When the text protocol query is switched to a binary protocol prepared statement, the errors again appear.

Can you try if the 2.1 beta release of MaxScale fixes this problem?

We installed the 2.1 beta-release, but were unable to test.
Logging on to socket worked fine in mysql command-line client, but php just got error
Can't create link: Connect failed: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)

tcp-dumping showed traffic from maxscale to mysql.

So it almost seems like there's some incompatibility with php in 2.1.0-beta...

Does the MaxScale error log provide any information as to why it fails?

Unfortunately not. It only states when connection is opened/closed

Is the /var/lib/mysql/mysql.sock configured in maxscale.cnf and is the file created when MaxScale starts?

Stopping MaxScale, removing any stale sockets and restarting MaxScale should help solve any problems caused by old socket files.

Yes, the socket in configured in maxscale.cnf, and created when MaxScale starts.

In the configuration you posted in the issue, the socket is defined with a different name:

[MyHotelProxyListener]

type=listener

service=MyHotelProxy

protocol=MySQLClient

port=13306

socket=/var/lib/mysql/myhotel.sock

Is this still configured the same? If so, please change it to /var/lib/mysql/mysql.sock.

Well, the socket is only used on the web-frontends, and I believe that I posted the configuration for the central server (that isn't recieving any traffic on the socket)
The configuration is correct, since traffic flows to the database. The only issue is that the amount of prepared statements we have doesn't work...

This seems to have been fixed by the 2.1 version of MaxScale.