Le 23/04/2018 à 23:07, PiBa-NL a écrit :
Hi List, Thierry (LUA maintainer), Christopher (Multi-Threading),
When im making a tcp connection to a (mail) server from a lua task this
error pops up randomly when using 'nbthread 4', the error luckily seems
pretty self explanatory, but ill leave that to the threading and lua
experts to come up with a fix ;) i think somehow the script or at least
its socket commands must be forced to always be executed on the same
thread? or perhaps there is another way..
Also i do wonder how far lua is safe to use at all in a multithreaded
program. Or would that become impossible to keep safe.?. But thats a bit
offtopic perhaps..
Line 240: recieve = mailer.receive(mailer, "*l")
[ALERT] 110/232212 (678) : Lua task: runtime error:
/root/haproxytest/test.lua:240: connect: cannot use socket on other thread.
Line 266: local mailer = core.tcp()
Line 267: ret = mailer.connect(mailer, self.mailserver,
self.mailserverport)
[ALERT] 110/232321 (682) : Lua task: runtime error:
/root/haproxytest/test.lua:267: connect: cannot use socket on other thread.
Let me know if there is a patch or something else i can test/check. Or
should configure differently.?.
Thanks in advance.
Hi Pieter,
I'm able to reproduce the same behavior. I checked the code and it seems
that when a task is registered in lua (core.register_task), this task
has no specific affinity with threads. It means it can be woken up and
processed on any threads. On the other hand, applets created in lua are
sticky on the thread which created them (and thus cosockets too, because
they inherit from the applets' thread_mask). So if you connect to a
server on a thread and woken up the task to read on another one, it fails.
So, I'm not a lua expert. And I don't know if you are supposed to do
that in HAProxy or not. Maybe there is another way to achieve the same
thing to workaround the problem. But here is a quick little patch you
can use to fix the bug (It seems to work, not sure). It change the
affinity with threads of lua's tasks. But Thierry must definitely review
it. Because I really don't know if this is the good way to fix the bug.
Also note that this patch will fix the problem of cosockets/applets
created by tasks registered in lua. I don't know if it's possible, but
if you can create them outside the lua's tasks and then use them in the
tasks context, it will be a problem.
Regards,
--
Christopher Faulet
>From b7fc496e5b5cadbb9a59f598bd9077ca466f3ddb Mon Sep 17 00:00:00 2001
From: Christopher Faulet <cfau...@haproxy.com>
Date: Wed, 25 Apr 2018 10:34:45 +0200
Subject: [PATCH] BUG/MINOR: lua/threads: Make tasks registered in lua sticky
to the current thread
PiBa-NL reported a bug with tasks registered in lua when HAProxy is started with
serveral threads. These tasks have not specific affinity with threads so they
can be woken up on any threads. So, it is impossbile for these tasks to handled
cosockets or applets, because cosockets and applets are sticky on the thread
which created them. It is forbbiden to manipulate a cosocket from another
thread.
So to fix the bug, tasks registered in lua are now sticky to the current thread.
This patch must be backported in HAProxy 1.8.
---
src/hlua.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/hlua.c b/src/hlua.c
index 60cf8f948..890766c73 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -5620,7 +5620,7 @@ static int hlua_register_task(lua_State *L)
if (!hlua)
WILL_LJMP(luaL_error(L, "Lua out of memory error."));
- task = task_new(MAX_THREADS_MASK);
+ task = task_new(tid_bit);
task->context = hlua;
task->process = hlua_process_task;
--
2.14.3
