Feature request: Run a script when upstream detected down/up

[Manlio Perillo]

Grzegorz Nosek ha scritto:
> On Wed, Apr 30, 2008 at 05:03:53AM -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. 
>> In any case, if you really dig deep, you can see that NGINX is asynch in that it always reads from a socket only when it is ready to be read (select/poll/epoll/kevent etc fires). 
>> But, as you know, NGINX uses non-blocking sockets. 
>> So when it wants to write to a socket (as far as my limited understanding goes), it doesn't wait for it to be ready-to-write. It just goes and does a write to the socket. If the kernel deems that the write would have blocked, it will return EAGAIN (see send(2)) , rather than block the caller, if that's what you're worried about.
> 
> The problem arises when nginx produces log messages faster than the
> logger can consume them. You can then:
> 1. drop messages
> 2. buffer them until the consumer catches up
> 3. block writes
> 
> None of these options is particularly nice, but if I were to implement
> an external log consumer for nginx, I'd slap a traditional syslog
> (514/udp) interface and be done with it, lost messages be damned (maybe
> just use a bigger send buffer for the socket).
> 

The RFC 3164 requires that each packet MUST not be greater then 1024 bytes.

> Note that if you buffer the log messages inside nginx, the buffer may
> actually grow infinitely large.
> 

Regards  Manlio Perillo