I had a quick question about
blocking system calls while writing Lua code to expand HAproxy functionality. From https://raw.githubusercontent.com/haproxy/haproxy/master/doc/lua.txt, I’ve been reading that it is discouraged to use io.*` calls as they’re blocking in nature, so I understand that when those blocking operations are happening, HAproxy thread will not be able to process other HTTP requests.
It definitely makes sense if they are done in
lua service/actions etc, however, does that hold true for
tasks as well?
From the doc,
The task does not have a timeout because it runs in the background along the HAProxy process life.
It seems that tasks are run in the background, and are different from the HAProxy process. So, is it okay to use
io.* calls in
task ? For example, is this a valid use-case of updating ACLs as it depends on reading files in tasks? haproxy-lua-examples/background_thread.lua at f5853013087642c0ed34ed47bea4c6efbf96dd29 · zareenc/haproxy-lua-examples · GitHub .
What if the disk operations are momentarily slow, will it block actual HTTP requests? Thank you in advance!
Good question, I don’t know the answer. I suggest you repost your question to the mailing list
firstname.lastname@example.org to get more responses.
@lukastribus Thank you for the response. I’ve posted the query on the mailing list now. For future readers, link here: Blocking IO in "lua tasks"
Yes, the background task are technically running in a thread which is also processing http requests, so blocking I/O block the thread.
While Lua perform slow I/O HAProxy does nothing waiting for data. If a broken disk spent 10s to open file, all the http requests actually processed by haproxy were blocked during 10s.
I’m pretty sure that HAProxy has a watchdog which kill the process if anything block for more than 2s. So the file system accès using Lua is quite dangerous.
This is a question of risk managment:
- if you want to check a little file each 10s, you can accept the risk
- if you want to transform haproxy in a static file server, the risk of failure is very high
- if you want to check or load file frequently, but you’re using SSD, maybe the risk is low
- If you need to access a low amount of static file, you can’t try to store it in a ram disk. The risk is very low.
FYI Aurelien DARRAGON responded to this too on the mailing list:
@thierry Thank you for your response, appreciate it.
It seems that if there’s a use-case to do blocking IO on disk, a better approach is using SPOE instead of lua. lua+haproxy integration is the wrong tool for the job.