Hi, Thanks for contributing.
I looked your code, I see a big problem. HAProxy is event driven, so we cannot execute blocking function. fopen is one of these fucntions. During the runtile, the filesystem access are not allowed. The right way for a transfer between haproxy and the filesystem is using the socket. WArning with maps. There are used by many people for loading ip geolocation list with contains billions of entries. All of these entrie copyed in a Lua tree will probably esceed the allowed ram. I other way, even if the memory is sufficient, these function is longer to execute. The event driven model wants quick execution functions in order to assure that haproxy continue to be responsive. I already work on this question, it is not so easy. First, the Lua code is periodically stopped to allow haproxy to do is job. These "stop" are invisible for the user. When the Lua executes a C function, the stop is no longer posssible. I think that a function like "pair" can be written for working with the "for" statement and list of maps. Juste for information, these values are already avalaibble using sample-fecthes mapper in Lua. I'm not opposite to write direct access function for Lua. "req_get_method" "req_get_path" "req_get_query" "req_get_uri" Thank you, Thierry On Thu, 3 Nov 2016 16:26:39 +0100 Willy Tarreau <[email protected]> wrote: > Hi Alex, > > On Wed, Nov 02, 2016 at 08:45:41PM -0400, Alex Maksutov wrote: > > Hi there, > > > > Our company is using LUA scripting a lot, and I've discovered some missing > > functions in the code. We've made a patch to fill these gaps, but I don't > > know how to make a pull request. So, I've made a copy of the haproxy > > repository and pushed my changes there. It's based on latest development > > version. > > > > Here is my commit: > > https://github.com/mediahubinc/haproxy/commit/4446ecddce3f5ec71e79f92e1fbc8eb3841f08e4 > > For a first submission it's not bad :-) > Please take a look at the file CONTRIBUTING. You'll see that here is > the right place to discuss patches. A few hints regarding your patch : > > - please do not mix code cleanups and real changes in the same patch, they > make reviews harder, and if for any reason a bisect later ends up on your > patch it's even less obvious what it changes. And in general when you > touch multiple areas at once, it's highly recommended to do them as > individual patches that are easier to review/revert in case of issues. > For example if your map changes cause trouble and we have to revert your > patch, we're forced to remove a lot of other features totally unrelated > to the maps. > > - please include a detailed commit message. All your commit says is the > subject line, which doesn't say anything about it. At least the info > you added here should be in the commit message. > > - do not forget to update the doc with your additions > > - you may get a faster response by CCing the various subsystem maintainers, > and in your case it happens that maps and Lua are handled by the same one > (Thierry). > > Since your changes are quite isolated, I personally have no problem with > getting them into 1.7 eventhough the release is coming soon once Thierry > blesses them, because the risk is low. And the code is clean. I'll let > Thierry comment on your work here. > > Thanks! > Willy >
