[MXS-2806] Add ability to stop/start Listener Created: 2019-12-17  Updated: 2020-10-07  Resolved: 2020-10-07

Status: Closed
Project: MariaDB MaxScale
Component/s: REST-API
Affects Version/s: None
Fix Version/s: 6.0.0

Type: New Feature Priority: Major
Reporter: Assen Totin (Inactive) Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Sprint: MXS-SPRINT-116

 Description   

In MaxScale we can (remotely) start/stop certain components like services; however, MaxScale does lacks the ability to start/stop a listener.

The main expected feature here is that all existing client connections (and related server connections) should be terminated - either immediately or after completing the current query; it would be nice to have a config option to chose termination mode.

This feature is useful in all cases when we want to ensure clients connect to the proper servers; a typical one is a service reconfiguration when all existing connections will still point to the old servers, which we want to avoid; currently the only way of doing this is a complete restart of the daemon, which may be undesired when done frequently or when MaxScale is engaged with multiple separate clusters.

It is understood that if the admin interface or REST API listener gets stopped, the corresponding management channel becomes unavailable.



 Comments   
Comment by markus makela [ 2019-12-18 ]

The stopping of services already stops all listeners. Stopping a service causes all listeners to stop accepting new connections. Stopping individual listeners would be logical but it wouldn't achieve what you want. If I'm reading it correctly, you want a mechanism that forcibly kicks out all active sessions connected to a service after it has been reconfigured. A "time-to-live" mechanism that forces a time limit on a connection's lifetime after a configuration change would be a reasonable solution to this problem. This would allow all sessions to gracefully close but it would prevent old sessions from hanging around for too long.

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