A simple solution can be a dedicated process, listening on localhost UDP, and replying to a simple query language.
The better place to collect stats seems to be in the pool_handling process (but stats collecting component has to be written).
The problem of a pool_handling process child is the case where the pool_handling process exits… PyFCGI will not reply anymore on local UDP…
A solution is to spawn a dedicated UDP server child from master process. Then the pool handling process will spawn a child for stats collection access. Both UDP server & stats collection process will communicate through a named pipe (with a name shared from the master process).
write the UDP server <-> stats collection IPC through named pipe #23
The idea is to allow stats & status fetching.
A simple solution can be a dedicated process, listening on localhost UDP, and replying to a simple query language.
The better place to collect stats seems to be in the pool_handling process (but stats collecting component has to be written).
The problem of a pool_handling process child is the case where the pool_handling process exits... PyFCGI will not reply anymore on local UDP...
A solution is to spawn a dedicated UDP server child from master process. Then the pool handling process will spawn a child for stats collection access. Both UDP server & stats collection process will communicate through a named pipe (with a name shared from the master process).
This component implies multiple tasks :
- write the stats collecting mechanism #20
- write the UDP server child #21
- write the stats collection child #22
- write the UDP server <-> stats collection IPC through named pipe #23
yannweb
додав(ла) до BETA version етапу 4 роки тому
The master process can start/monitor the shared memory and the semaphore for Stats proc & pool_handling proc IPC…
Note : a single semid can be use for the whole programm, a single semid with 3 semaphores.
the existing pool idle semaphore
the request counter semaphore
the stats proc <-> pool_handler proc IPC semaphore
The stats collection child is not needed :
The master process can start/monitor the shared memory and the semaphore for Stats proc & pool_handling proc IPC...
Note : a single semid can be use for the whole programm, a single semid with 3 semaphores.
- the existing pool idle semaphore
- the request counter semaphore
- the stats proc <-> pool_handler proc IPC semaphore
The idea is to allow stats & status fetching.
A simple solution can be a dedicated process, listening on localhost UDP, and replying to a simple query language.
The better place to collect stats seems to be in the pool_handling process (but stats collecting component has to be written).
The problem of a pool_handling process child is the case where the pool_handling process exits… PyFCGI will not reply anymore on local UDP…
A solution is to spawn a dedicated UDP server child from master process. Then the pool handling process will spawn a child for stats collection access. Both UDP server & stats collection process will communicate through a named pipe (with a name shared from the master process).
This component implies multiple tasks :
The stats collection child is not needed :
The master process can start/monitor the shared memory and the semaphore for Stats proc & pool_handling proc IPC…
Note : a single semid can be use for the whole programm, a single semid with 3 semaphores.
closed by b3af92459e
Something is not working duplicate
This issue or pull request already exists enhancement
New feature help wanted
Need some help invalid
Something is wrong question
More information is needed Tests
Tests using check or unittests wontfix
This won't be fixed _core
About PyFCGI internal components _deployment _libpyfcgi
About PyFCGI Python components
Термін виконання не встановлений.
Видалення гілки НЕЗВОРОТНЕ. Дію не можна скасувати. Продовжити?