[modwsgi] Re: Django on Synology

Hi Graham. Ok a (maybe) interesting update for you. I did have a play with Docker but didn't get very far. I ran into issues with passing port 80 traffic from sinology through to docker to be processed. However. I did have lots of success using the Virtual Machine app to create a

Re: [modwsgi] Re: Django on Synology

> On 7 Feb 2018, at 5:34 am, cdaviesbarn...@gmail.com wrote: > > Hi Graham. > > Ok a (maybe) interesting update for you. > > I did have a play with Docker but didn't get very far. I ran into issues > with passing port 80 traffic from sinology through to docker to be processed. >

[modwsgi] mod_wsgi and Apache output filters - mod_ratelimit

Hi, I've run into an issue with a long-in-use mod_wsgi setup with WSGI daemon processes. Specifically, the output of the application running under mod_wsgi does not appear to be passed through the configured Apache output filters, at least not with a rate limiting filter from the built-in

Re: [modwsgi] mod_wsgi and Apache output filters - mod_ratelimit

How are you measuring the rate at which data is being returned? Is there a specific client command you are using? If I know that I can test. Include any example of running it and what output you see and expect to see. Thanks. Graham > On 7 Feb 2018, at 8:56 am, Charles Cazabon

Re: [modwsgi] mod_wsgi and Apache output filters - mod_ratelimit

I can confirm the behaviour you are seeing. The rate_limit output filter is appearing in the list of output filters. FILTER BYTYPE:DEFLATE FILTER byterange FILTER content_length FILTER http_header FILTER http_outerror FILTER rate_limit FILTER reqtimeout FILTER core I can only assume that the

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

> On 7 Feb 2018, at 1:52 pm, Jesus Cea wrote: > > I find annoying that mod_wsgi doesn't log when it decides to restart a > daemon process because it becomes unresponsive. It could be useful even > log it when the maximum request number is reached (if defined) and the > daemon is

Re: [modwsgi] mod_wsgi and Apache output filters - mod_ratelimit

On Tuesday, February 6, 2018 at 4:46:36 PM UTC-6, Graham Dumpleton wrote: > > How are you measuring the rate at which data is being returned? Is there a > specific client command you are using? If I know that I can test. Include > any example of running it and what output you see and expect to

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

BTW, you can see example of stack trace generated when request-timeout occurs in recent mailing list discussion at: https://groups.google.com/d/msg/modwsgi/_i6MGs6fh6w/nH3x7_nuAwAJ Graham > On 7 Feb 2018, at 1:55 pm,

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

There is an actual example of what you see in the logs further down in that post. [Mon Feb 05 21:11:52.378725 2018] [wsgi:info] [pid 31535:tid 140409583761152] mod_wsgi (pid=31535): Exiting process 'blah'. [Mon Feb 05 21:11:52.404508 2018] [wsgi:info] [pid 31550:tid 140409652811520] mod_wsgi

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

On 07/02/18 03:55, Graham Dumpleton wrote: > On this specific issue, it will logs lots of stuff if you have Apache log > level set to info. > > LogLevel info > > For request-timeout expiring it even logs stack traces for you if it can so > you can see where it gets stuck. Not documented

Re: [modwsgi] mod_wsgi and Apache output filters - mod_ratelimit

On Tuesday, February 6, 2018 at 4:46:36 PM UTC-6, Graham Dumpleton wrote: > > How are you measuring the rate at which data is being returned? Is there a > specific client command you are using? If I know that I can test. Include > any example of running it and what output you see and expect to

[modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

I find annoying that mod_wsgi doesn't log when it decides to restart a daemon process because it becomes unresponsive. It could be useful even log it when the maximum request number is reached (if defined) and the daemon is recycled. Beside that, it could be really useful mod_wsgi call

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

On 07/02/18 04:01, Graham Dumpleton wrote: > BTW, you can see example of stack trace generated when request-timeout > occurs in recent mailing list discussion at: > >     https://groups.google.com/d/msg/modwsgi/_i6MGs6fh6w/nH3x7_nuAwAJ Humm. If you are refering to this comment of you: """ You

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

> On 7 Feb 2018, at 3:14 pm, Jesus Cea wrote: > > On 07/02/18 03:55, Graham Dumpleton wrote: >> On this specific issue, it will logs lots of stuff if you have Apache log >> level set to info. >> >>LogLevel info >> >> For request-timeout expiring it even logs stack traces

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

On 07/02/18 05:14, Jesus Cea wrote: > On 07/02/18 03:55, Graham Dumpleton wrote: >> On this specific issue, it will logs lots of stuff if you have Apache log >> level set to info. >> >> LogLevel info >> >> For request-timeout expiring it even logs stack traces for you if it can so >> you can

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

I could be naughty as not using: https://docs.python.org/3/c-api/reflection.html#c.PyFrame_GetLineNumber int f_lasti;/* Last instruction if called */ /* Call PyFrame_GetLineNumber() instead of

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

Fixed in: https://github.com/GrahamDumpleton/mod_wsgi/commit/f635d7f76380e9826b35d9d3ef09c2176a3e14d8 Graham > On 7 Feb 2018, at 3:35 pm, Graham Dumpleton > wrote: > >

Re: [modwsgi] mod_wsgi process restarting (not) logging and "faulthandler"

On 07/02/18 05:22, Graham Dumpleton wrote: > I'll look into. Python stack traces are a bit of a pain as they don't > give a separate stack frame for when you call a function which is > actually implemented in C code. Usually though one can at least work > out the line in calling code where C