You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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 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 .
The text was updated successfully, but these errors were encountered: