[MXS-1550] Proxy side net_write_timeout and net_read_timeout Created: 2017-11-29  Updated: 2024-01-04  Resolved: 2019-06-10

Status: Closed
Project: MariaDB MaxScale
Component/s: mariadbbackend
Affects Version/s: None
Fix Version/s: 2.5.0

Type: New Feature Priority: Major
Reporter: dapeng huang Assignee: Marko Rajala (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Sprint: MXS-SPRINT-82, MXS-SPRINT-83

 Description   

Put a proxy(mxs) between client and db will let server variables net_write_timeout and net_read_timeout not work, for example,if current client is hang,server's reponse cannot send to client, it will block on tcp send operation, with time gos on, it will trigger net_write_timeout to break this conneciion, but if put proxy(mxs) in the middle, if proxy is health ,server can always send data to proxy without block;

Proposal:
Use session track mechanism to track latest net_write_timeout/net_read_timeout value, and apply it in proxy side;



 Comments   
Comment by markus makela [ 2017-11-29 ]

The latest network write/read is already tracked for the connection_timeout feature. It covers both read and write timeouts and controls how long a client can be idle before the connection is closed.

Comment by dapeng huang [ 2017-11-29 ]

connection_timeout and net_write_timeout are different things,

The connection_timeout parameter is used to disconnect sessions to MariaDB
MaxScale that have been idle for too long. The session timeouts are disabled by
default.

The net_write_timeout is number of seconds to wait for a block to be written to a connection before aborting the write.

Comment by markus makela [ 2017-11-29 ]

Oh yes, I think we could add a similar mechanism into MaxScale. We already know if network writes are buffered so the only thing to add is to see if they have been buffered for a long time.

We could handle the read timeouts by comparing the last read and write times for a client socket. If a client sends a request the read timestamp will be updated. When data is written to the client socket, the write timestamp is updated. By evaluating write_timestamp - read_timestamp > net_read_timeout, we will know if a client request is taking a long time.

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