I really appreciate the response. This confirms, that "everything in
runtime mode" uses the same thread pool as HTTP workers. This also says
that the onlytime we can use "blocking IO" is in "initialization mode",
ie, at HAproxy startup/reloads.
Happy to help!
Considering what we've already established in this email, it looks like
HAProxy has no way to serve a "static file" which changes after HAproxy
has been initialized. @Aurelien, please confirm! This seems like a big
limitation, there has to be a workaround. Is it just acceptable in
HAproxy world to "reload instead", every time a file is modified on disk?
Right now I can think about 2 different options:
You could have a basic webserver on the host serving those files locally
via HTTP.
And from your task use core.httpclient to safely fetch/parse the file
and update your global variable periodically.
Or
Register a custom cli from lua script (core.register_cli).
Then from a custom system script watch for files changes (or check
periodically), and when updating is required, use local haproxy
stats socket from your script to execute your custom lua cli
that is in charge of updating the global variable.
(Passing arguments to custom lua cli is supported)
Note: Alternatively this solution can be implemented with lua service +
local curl/wget with payload from the system script to trigger the service.
But if anyone out there knows about a better approach, please feel free
to share your thoughts on this.
The only non-blocking functions available to use is via "socket class".
Is it too crazy if we use "socket object" to do network IO to a process
we write that acts as a proxy to do disk operations?
Considering SPOE requires much more efforts to setup compared to lua,
depending on your needs you could consider sticking to lua coupled with
a basic tcp or http middleware that does the file to tcp/http proxy
(either existing webserver or custom script using socat/netcat).
Aurelien
