[MXS-3108] Possibility to inject filters into running sessions Created: 2020-08-10 Updated: 2020-12-07 Resolved: 2020-12-01 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Core |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Johan Wikman | Assignee: | markus makela |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Sprint: | MXS-SPRINT-119, MXS-SPRINT-120 | ||||||||
| Description |
|
Currently it is at runtime possible change (add or remove) the filters of a service, but it is not possible to change the filters of a running session. Being able to add/remove a filter to/from a session would not only add architectural clarity, but be a powerful feature that could be used for many purposes. Currently, when a problem occurs in a production system, the actions available for sorting out the problem are quite limited; basically you can turn on info level logging. Typically it is also quite hard to repeat problems occurring in a production environment. And typically it is also rather straightforward to fix problems once their cause is known. Not finding out the cause is often caused by now having enough information. With a possibility to inject filters at runtime, there could be particular debug module that would make extensive logging, which could be injected into a running session for collecting information and then be removed. The potential for extensive logging would impose no cost whatsoever when it is not being used. It would also make it possible to easily test what impact a particular filter has by adding and then removing it from a running session. A more speculative use-case would the possibility to change the filters of a long-running session during certain time-periods of the day. Being able to add/remove filters of a running session would implicitly make it trivial to measure the cost of a particular filter in the routing chain. |
| Comments |
| Comment by markus makela [ 2020-11-12 ] |
|
Injecting filters into an active session is relatively straightforward now that the objects themselves can be interacted with. For the ServiceEndpoint class this can be done by:
With this, the only big problem is how the session interacts with the mxs::Endpoint objects downstream. Ever since 2.5 there can be multiple filter chains for a single session; one for each ServiceEndpoint. In addition, not all branches in the tree that is formed from the endpoints is connected which makes it more complex. The problem that remains is: how to identify which session and which node in the tree to inject the filter to. One solution would be to only allow addition of filters to the MXS_SESSION object itself. Right now, it only calls the downstream component and it could have a routing chain similar to the ServiceEndpoint. This would remove the problem of identifying the node into which the filter is added. Another aspect of this is that starting a new filter session can be done only at certain points. This depends on the filter but one obvious case is that a new session must not be started when a query has been routed but no request has been received. This in turn implies tracking of queries and their responses. As for the benefits of debuggability; in practice the ability to turn on log_info for a particular session would provide more actionable output than a new filter that logs all the information. The downside of filters is that the filter itself wouldn't know about the routing decisions of the router or what the MaxScale core does. However, it would be extremely valuable to be able to enable filters when some condition is met. This would allow automated logging of problematic sessions which in turn would make it easy to solve problems (assuming the logging is useful). |
| Comment by markus makela [ 2020-12-01 ] |
|
The chosen solution was to only allow addition of filters to the session object. This means that the filters defined for services cannot be disabled at runtime for individual sessions. The filters are added before any existing filters and will be first link in the routing chain. |