Hi! I am going to outline the future direction of the funnel plugin, partly to kickstart discussions for the hackathon in Hamburg (in the architecture areas I am looking at anyway).
The code in my branch on launchpad is kind of a 'feature complete prototype'. We are using it internally at Hyves (where I work) for a variety of purposes. Apart from any major failings we have here, the current branch will probably not get any more functionality or changes. I don't assume anyone else is actively using the plugin, but it is usable for the original use case outlined in the blueprint in launchpad (a proxy instance per mysqld in a load balanced replication slave farm). I have started a new branch (not yet on launchpad) that will implement the feature set of the current plugin, plus some longer term goals, such as multiple backends, dynamic add/remove of backends, query load balancing and support for multiple users/databases. I would also like a cleaner code structure than I have now and I intend to get the code more closely aligned with the rest of the project's code, for instance creating patches for the connection pool used by the proxy plugin instead of implementing a completely separate pool (as it is now in the funnel). The goals (in no particular order here) include: * backlog support in the chassis core * changes to the protocol state machine to make the backlog usable * enforceable connection size limits to a connection pool, per user/db * dynamically add/remove a backend * optional scripting layer (we do not use LUA in the funnel plugin, and it would be nice to make LUA support a compile time option) * advanced statistics on the backends, connection pools, chassis as a whole etc Some of these things (backlog, state machine changes) are already present in the current prototype, but they are probably not done 'correctly' and are mixed into my branch with other changes. I would like to get feedback on whether the above types of things would be wanted/needed/acceptable in the chassis/mysql-proto core, and if anyone has ideas on how they are best implemented. My immediate goals: * backlog in the chassis core * hooks for the backend 'objects' and connection pool 'objects' whereby a plugin can influence their behavior. This may be something like callbacks when adding or removing or requesting current state. I see this as essential for the goal of dynamically adding/removing backends and limiting connection pool size. Obviously the above changes should have no impact, performance or otherwise on plugins that do not use them. That was just a quick brain dump from what we have been talking about internally here at work... any further points or discussion would be appreciated. Cheers -- Nick Loeve _______________________________________________ Mailing list: https://launchpad.net/~mysql-proxy-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~mysql-proxy-discuss More help : https://help.launchpad.net/ListHelp
