27 messages in ru.sysoev.nginxRe: Feature request: Run a script whe...
FromSent OnAttachments
Rt IbmerApr 28, 2008 8:44 am 
Cliff WellsApr 28, 2008 10:20 am 
mikeApr 28, 2008 11:53 am 
Rt IbmerApr 28, 2008 2:02 pm 
Cliff WellsApr 28, 2008 2:18 pm 
Manlio PerilloApr 28, 2008 2:37 pm 
Rt IbmerApr 28, 2008 6:10 pm 
Rt IbmerApr 28, 2008 6:19 pm 
Manlio PerilloApr 29, 2008 1:18 am 
Manlio PerilloApr 29, 2008 1:25 am 
Rt IbmerApr 29, 2008 8:11 am 
François BattailApr 29, 2008 10:46 am 
Rt IbmerApr 29, 2008 1:41 pm 
Manlio PerilloApr 29, 2008 1:57 pm 
François BattailApr 29, 2008 2:27 pm 
Aleksandar LazicApr 29, 2008 2:36 pm 
François BattailApr 29, 2008 11:20 pm 
Mansoor PeerbhoyApr 30, 2008 1:46 am 
Manlio PerilloApr 30, 2008 2:36 am 
François BattailApr 30, 2008 3:54 am 
Mansoor PeerbhoyApr 30, 2008 5:03 am 
Grzegorz NosekApr 30, 2008 5:18 am 
Cliff WellsApr 30, 2008 10:40 am 
Manlio PerilloApr 30, 2008 12:16 pm 
Manlio PerilloMay 1, 2008 2:42 am 
Grzegorz NosekMay 1, 2008 11:28 am 
Manlio PerilloMay 1, 2008 12:02 pm 
Actions with this message:
Paste this link in email or IM:
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/upActions...
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