Feature request: Run a script when upstream detected down/up
grzegorz.nosek at gmail.com
Wed Apr 30 16:19:17 MSD 2008
On Wed, Apr 30, 2008 at 05:03:53AM -0700, Mansoor Peerbhoy wrote:
> 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.
More information about the nginx