The scope of this ticket is to see what we can do to improve the mod_proxy initialization steps, especially when ProFTPD is being run with "ServerType inetd", as for xinetd; see #196 .
I suspect that the problems there are due to mod_proxy's use of multiple SQLite database files, and race conditions between multiple processes competing for those same files at the same time. So, my plan for this is to do the following:
- Reproduce this behavior locally
- Determine if using a single application-level mutex/lockfile, in
mod_proxy, can address this
Having such a mutex/lockfile might work -- but it will also inevitably add some latency to the process initialization, while the process waits for all competing processes to release the lockfile. Still, that would be better behavior than seen in #196 .
The scope of this ticket is to see what we can do to improve the
mod_proxyinitialization steps, especially when ProFTPD is being run with "ServerType inetd", as forxinetd; see #196 .I suspect that the problems there are due to
mod_proxy's use of multiple SQLite database files, and race conditions between multiple processes competing for those same files at the same time. So, my plan for this is to do the following:mod_proxy, can address thisHaving such a mutex/lockfile might work -- but it will also inevitably add some latency to the process initialization, while the process waits for all competing processes to release the lockfile. Still, that would be better behavior than seen in #196 .