Issue #1043 new

internal WSGI server accept()'s connections even when no worker threads are available

Anonymous created an issue

Symptom: when a multitude of connections is made all at once, faster than the worker threads can process them, the internal server may run out of file descriptors and stop responding to requests altogether. This scenario may occur during an attack or simply during heavy use.

Cause: the web server accept()'s new connections in a loop (in tick()). New connections are then placed on the queue, where the worker threads can take them up. accept() runs even when no worker threads are available, thus eating up file descriptors.

The correct behavior would be not to run accept() until at least one worker thread is free.

Reported by mnagy@port70.net

Comments (1)

  1. Anonymous

    A possible solution: in `ThreadPool.init`, pass the threadpool size to the Queue object as a maximum number of slots.

    Instead of this:

    self._queue = Queue.Queue()
    

    Use this:

    self._queue = Queue.Queue(min)
    

    Result: self._queue.put() will block (thus blocking the main server loop) until a slot is available.

    Actually, the number of slots in the Queue doesn't have to match the size of the threadpool; it may be an arbitrary number, larger or smaller. It just can't be infinite.

  2. Log in to comment