Waitress how setup channel_timeout and max size limits

[Michal Seidl]

Hello,
I can not figure out how to setup timeout (request processing takes to much time) and limit for output data.

I am starting server like this.

 serve(application,
        host='0.0.0.0',
        port=port,
        cleanup_interval=2,
        channel_timeout=4
      )

I am using Werkzeug Request and Response objects and jsonrpcserver dispatch method to delegate request to my processing method. In this method I have

time.sleep(timeToSleep)
 

But even I setup timeToSleep much bigger (120s) than channel_timeout (4s) I can seen that the request is always processed and return to client?

For response size limit I can not even find suitable setting parameter.

It would be nice if in both cases (timeout, maxsize reponse) server will be able to stop/cancel/kill the corresponding process/thread/call and return some meaningful response.

Thanks for any help.

[Michal Seidl]

Hello,
I can not figure out how to setup timeout (request processing takes to much time) and size limit for output data.

I am starting server like this:

      serve(application,
        host='0.0.0.0',
        port=port,
        cleanup_interval=2,
        channel_timeout=4
      )
 

I am using Werkzeug Request and Response objects and jsonrpcserver dispatch method to delegate request to my processing method. In this method I have

time.sleep(timeToSleep)
 

But even I setup timeToSleep much bigger (30s) than channel_timeout (4s) I can seen that the request is always processed sucefully?

For output size limit I even can not find any setting argument.

In best case, if one of these limit would be fulfill the server stop/cancel/kill according process/thread and returns to client some meaningful response.

Thanks for any help.

[Michael Merickel]

Waitress is a threaded WSGI server and there isn't a safe way to kill threads inside of a process while they are blocked executing synchronous code. Even if the underlying channel is closed, the thread continues until the request is completed processing and then the response is simply discarded because the channel is gone. This is definitely a limitation of the thread-based model but in practice isn't generally a big deal. If you do need fine-grained control per-request, then a request-per-process server like gunicorn or uwsgi can help here because they can kill the process if it's taking too long to handle a request. There are pros and cons to the different approaches in terms of control, memory usage, etc.

- Michael

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/88812140-6abf-4403-af8c-d2639418a543%40googlegroups.com.

[Bert JW Regeer]

Hey Michal,

Unfortunately there is nothing that will cause Waitress to kill a thread, because killing a thread in Python is not possible. The channel_timeout refers to how long a keep-alive connection stays open, a request that is processing in the WSGI thread will still be considered open, and active. The documentation around this probably needs a bit more work.

What you want is not possible with waitress.

Bert

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/e2f650bb-fdc7-4a72-a769-129280354c15%40googlegroups.com.

[Michal Seidl]

Thanks both Michael and Bert for explanation. process x thread
Yes the documentation confuse me a little bit specially this sentence in
channel_timeout docs.

"Inactive" is defined as "has received no data from a client and has
sent no data to a client".

Best regards Michal

On 5/20/20 10:06 PM, Bert JW Regeer wrote:
> Hey Michal,
>
> Unfortunately there is nothing that will cause Waitress to kill a
> thread, because killing a thread in Python is not possible. The
> channel_timeout refers to how long a keep-alive connection stays open, a
> request that is processing in the WSGI thread will still be considered
> open, and active. The documentation around this probably needs a bit
> more work.
>
> What you want is not possible with waitress.
>
> Bert
>
>> On May 20, 2020, at 06:53, Michal Seidl <michal...@gmail.com

>> <mailto:michal...@gmail.com>> wrote:
>>
>> Hello,
>> I can not figure out how to setup timeout (request processing takes to
>> much time) and size limit for output data.
>>
>> I am starting server like this:
>>
>>
>> |serve(application, host='0.0.0.0', port=port, cleanup_interval=2,
>> channel_timeout=4 )
>> |
>>
>> I am using Werkzeug |Request| and |Response| objects and
>> |jsonrpcserver dispatch| method to delegate request to my processing
>> method. In this method I have
>>
>> |time.sleep(timeToSleep)
>> |
>>
>> But even I setup |timeToSleep| much bigger (30s) than |channel_timeout
>> (4s)| I can seen that the request is always processed sucefully?
>>
>>
>> For output size limit I even can not find any setting argument.
>>
>>
>> In best case, if one of these limit would be fulfill the server
>> stop/cancel/kill according process/thread and returns to client some
>> meaningful response.
>>
>>
>> Thanks for any help.
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "pylons-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to pylons-discus...@googlegroups.com

>> <mailto:pylons-discus...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/pylons-discuss/e2f650bb-fdc7-4a72-a769-129280354c15%40googlegroups.com

>> <https://groups.google.com/d/msgid/pylons-discuss/e2f650bb-fdc7-4a72-a769-129280354c15%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pylons-discus...@googlegroups.com

> <mailto:pylons-discus...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pylons-discuss/ED813905-230F-4C87-9D64-AA5BCBEEDC2E%400x58.com
> <https://groups.google.com/d/msgid/pylons-discuss/ED813905-230F-4C87-9D64-AA5BCBEEDC2E%400x58.com?utm_medium=email&utm_source=footer>.

[Michael Merickel]

Yeah it's possible for the channel / socket to close (client hangup, channel timeout, etc) while the WSGI app is still processing the request. The WSGI execution thread will have no idea until it tries to actually write the response at which point an exception may be raised but this is usually after the WSGI app is done processing the request unless you go out of your way to stream a response.

- Michael

> To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/67899690-b617-02ba-cbbb-3dc182d2021d%40gmail.com.