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

[Grzegorz Nosek]

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).

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

> ----- Original Message -----
> From: "Manlio Perillo" <manlio_perillo at libero.it>
> 
> This is not as easy as it seems.
> First of all with the current architecture of Nginx, writing to the 
> error log is assumed to be synchronous.
> 
> This means that if you want to send log messages to a TCP server the 
> performance will be bad.
> 
> You can use an UDP connection, but what happens if Nginx sends data more 
> quickly then the server is able to read?
> UDP has no flow control.

QFT.

Best regards,
 Grzegorz Nosek