On Thu, May 13, 2021 at 12:24:02PM +0200, Tim Düsterhus wrote:
> > So what I'm proposing is to simply change vars_get_by_name() to call
> > register_name() with alloc=0 in order to fix this mess. We can then
> > check during 2.5 how to refine this to also consider the scope with
> > the variable's
Willy,
On 5/13/21 11:40 AM, Willy Tarreau wrote:
Yes, and it's still unclear to me how this storage is currently arranged,
(i.e. why only store names?) I should have a look for 2.5 probably.
OK now I got a better view of it and there is some misunderstanding in
the way the names are being
Hi guys,
On Wed, May 12, 2021 at 09:44:28AM +0200, Willy Tarreau wrote:
> On Wed, May 12, 2021 at 09:12:25AM +0200, Tim Düsterhus wrote:
> > Willy,
> >
> > On 5/12/21 7:47 AM, Willy Tarreau wrote:
> > > Interestingly, the code for variables was initially made for the config,
> > > so it doesn't
On Wed, May 12, 2021 at 02:12:44PM -0300, Joao Morais wrote:
> > It's not a matter of first or second access. It's that the function
> > you used initially resulted in always allocating an entry for the
> > variable's name, causing some huge memory usage for those who were
> > using them like maps
> Em 12 de mai. de 2021, à(s) 02:47, Willy Tarreau escreveu:
>
> On Tue, May 11, 2021 at 05:41:28PM -0300, Joao Morais wrote:
>
>> Just to confirm how it works, I created the snippet below:
>>
>>http-request lua.auth ## assigning txn.core
>>http-request return lf-string
On Wed, May 12, 2021 at 09:12:25AM +0200, Tim Düsterhus wrote:
> Willy,
>
> On 5/12/21 7:47 AM, Willy Tarreau wrote:
> > Interestingly, the code for variables was initially made for the config,
> > so it doesn't seem to destroy variable names when they're released since
> > that was pointless
Willy,
On 5/12/21 7:47 AM, Willy Tarreau wrote:
Interestingly, the code for variables was initially made for the config,
so it doesn't seem to destroy variable names when they're released since
that was pointless with the config. I think that code should be revisited
in 2.5 to improve the
On Tue, May 11, 2021 at 05:41:28PM -0300, Joao Morais wrote:
>
>
> > Em 10 de mai. de 2021, à(s) 18:04, Willy Tarreau escreveu:
> >
> > On Mon, May 10, 2021 at 10:41:36PM +0200, Willy Tarreau wrote:
> >>> core.register_action("auth", { "http-req" }, function(txn)
> >>>
> Em 10 de mai. de 2021, à(s) 18:04, Willy Tarreau escreveu:
>
> On Mon, May 10, 2021 at 10:41:36PM +0200, Willy Tarreau wrote:
>>> core.register_action("auth", { "http-req" }, function(txn)
>>> txn:set_var("txn.code", 401, true)
>
> So the problem
On Mon, May 10, 2021 at 10:41:36PM +0200, Willy Tarreau wrote:
> > core.register_action("auth", { "http-req" }, function(txn)
> > txn:set_var("txn.code", 401, true)
So the problem is exactly here and it works as designed. This
argument "ifexist" was
On Mon, May 10, 2021 at 07:59:56AM -0300, Joao Morais wrote:
> Hello again! Here are the snippets running with 2.4-dev18 - docker image
> haproxy:2.4-dev18-alpine:
>
> $ cat h.cfg
> global
> log stdout format raw local0
> lua-load /tmp/h/svc1.lua
> lua-load /tmp/h/svc2.lua
> defaults
>
11 matches
Mail list logo
