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
added this to the BETA version milestone 5 years ago
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