

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
27 messages in ru.sysoev.nginxRe: Feature request: Run a script whe...| From | Sent On | Attachments |
|---|---|---|
| Rt Ibmer | Apr 28, 2008 8:44 am | |
| Cliff Wells | Apr 28, 2008 10:20 am | |
| mike | Apr 28, 2008 11:53 am | |
| Rt Ibmer | Apr 28, 2008 2:02 pm | |
| Cliff Wells | Apr 28, 2008 2:18 pm | |
| Manlio Perillo | Apr 28, 2008 2:37 pm | |
| Rt Ibmer | Apr 28, 2008 6:10 pm | |
| Rt Ibmer | Apr 28, 2008 6:19 pm | |
| Manlio Perillo | Apr 29, 2008 1:18 am | |
| Manlio Perillo | Apr 29, 2008 1:25 am | |
| Rt Ibmer | Apr 29, 2008 8:11 am | |
| François Battail | Apr 29, 2008 10:46 am | |
| Rt Ibmer | Apr 29, 2008 1:41 pm | |
| Manlio Perillo | Apr 29, 2008 1:57 pm | |
| François Battail | Apr 29, 2008 2:27 pm | |
| Aleksandar Lazic | Apr 29, 2008 2:36 pm | |
| François Battail | Apr 29, 2008 11:20 pm | |
| Mansoor Peerbhoy | Apr 30, 2008 1:46 am | |
| Manlio Perillo | Apr 30, 2008 2:36 am | |
| François Battail | Apr 30, 2008 3:54 am | |
| Mansoor Peerbhoy | Apr 30, 2008 5:03 am | |
| Grzegorz Nosek | Apr 30, 2008 5:18 am | |
| Cliff Wells | Apr 30, 2008 10:40 am | |
| Manlio Perillo | Apr 30, 2008 12:16 pm | |
| Manlio Perillo | May 1, 2008 2:42 am | |
| Grzegorz Nosek | May 1, 2008 11:28 am | |
| Manlio Perillo | May 1, 2008 12:02 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Feature request: Run a script when upstream detected down/up | Actions... |
|---|---|---|
| From: | Manlio Perillo (manl...@public.gmane.org) | |
| Date: | Apr 30, 2008 12:16:04 pm | |
| List: | ru.sysoev.nginx | |
Cliff Wells ha scritto:
On Wed, 2008-04-30 at 05:03 -0700, Mansoor Peerbhoy wrote:
Manlio,
Yes, I see what you're saying. It is always going to be a problem if the listener cannot consume the data fast enough.
I think if Nginx only updated counters (similar to OpenVZ's bean counters) this would not be an issue and would work well with the shared memory/virtual file approach (and fits better with the idea of event monitoring vs logging/post-mortem). Rather than a stream of data you have a "file" of fixed size that's constantly updated. It also simplifies the parsing of the data by an external application.
There is a potential problem with this solution. To be able to write atomically all this information, Nginx have to use a spin lock to lock the memory region.
However the default implementation in Nginx uses an atomical variable visible only by Nginx.
This means that an external process have no way to sinchronize memory access with Nginx, and it may read inconsistent values.
Moreover if the external process can synchronize with Nginx there is the risk that this external process will keep the lock for too much time, thus blocking Nginx.
The solution is to only store atomic_t values in the shared memory, so that it can atomically updated.
As an example /tmp/nginx/01 /tmp/nginx/01/address /tmp/nginx/01/name /tmp/nginx/01/tries /tmp/nginx/01/down
where 01 is the upstream peer number, and only the `tries` and `down` files will be updated (and they will contain an integer value in binary format).
If a virtual file system (like /proc) were used, then it should also be possible to use inotify (or similar) from external apps to be notified of events (although this might be too busy).
This should work with a normal filesystem too.
Regards, Cliff
Regards Manlio Perillo







