Feature request: Run a script when upstream detected down/up
manlio_perillo at libero.it
Thu May 1 13:42:39 MSD 2008
Grzegorz Nosek ha scritto:
> 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).
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
More information about the nginx