So.. should redundant expansions go into 3.0.5? They would work like this: instantiate { ... redundant-load-balance my_sql { sql1 sql2 sql3 } } You can already use "my_sql" in the "authorize" section, which is nice. This feature would allow you to use "my_sql" in expansions: update reply { Filter-Id := "%{my_sql:SELECT ...}" } The server core will automatically find *one* of the listed modules (sql1, sql2, or sql3), and call it. This feature has long been requested,and it's finally in the "master" branch. The question is whether it should go into the 3.0.5 release. Since the connection pools now support a "retry_delay" parameter, the cost of querying a "down" SQL server is essentially zero. In v2, the server would usually try to reconnect to SQL for evcery request. In v3, the "retry_delay" makes the "redundant-load-balance" blocks more useful. SQL servers which are down are effectively remove from the redundant list, until "retry_delay" seconds have passed. These changes increase the performance of the server, and make problems much less notable. Alan DeKok.
On Fri, Nov 14, 2014 at 02:23:27PM -0500, Alan DeKok wrote:
So.. should redundant expansions go into 3.0.5? They would work like this: ... This feature has long been requested,and it's finally in the "master" branch. The question is whether it should go into the 3.0.5 release.
Looks like a nice feature. The code looks OK at a quick glance. It's been a couple of months since 3.0.4 - maybe release 3.0.5 now, merge this immediately after, to give a couple of months public testing on 3.0.x, then release it as part of 3.0.6 in 2-3 months? Thanks Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Matthew Newton wrote:
Looks like a nice feature. The code looks OK at a quick glance.
Once you figure things out, long-term problems often have simple solutions.
It's been a couple of months since 3.0.4 - maybe release 3.0.5 now, merge this immediately after, to give a couple of months public testing on 3.0.x, then release it as part of 3.0.6 in 2-3 months?
Sounds reasonable. After that, we'll stop new features in 3.0. The goal is to do all new development in the "master" branch, for 3.1. Alan DeKok.
participants (2)
-
Alan DeKok -
Matthew Newton