I just tried to upgrade mod_wsgi from 3.5 to current 4.4.10. Apache
2.4.12, under Solaris 10.
Compilation is flawless. I didn't touch apache httpd.conf. Apache works
when making non-WSGI requests. But WSGI requests fail leaving this error
in the apache logs:
[Thu Mar 19 04:00:58.428157 2015]
On 19/03/15 09:23, Graham Dumpleton wrote:
By installing mod_wsgi-express it will confirm whether that
separately works without upsetting your main Apache installation.
It fails:
[jcea@babylon5 /]$ telnet 127.0.0.1
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET
On 19/03/15 16:06, Jesus Cea wrote:
If it doesn't work, then I will describe how to use 'truss' to track
down the system call which is giving the invalid argument error. Am
guessing it maybe writev() calls or equivalent.
You are right:
[root@babylon5 /]# truss -p 6935 -p 6948 -p 6934 21
On 23/03/15 02:13, Graham Dumpleton wrote:
My memory is that truss allows you to specify certain system
functions which you want verbose display of arguments and return
value.
From memory:
-v writev
Can you see if you can get extra information that way about the
arguments?
On 24/03/15 04:19, Graham Dumpleton wrote:
On Tuesday, 24 March 2015 14:08:25 UTC+11, jcea wrote:
On 23/03/15 02:13, Graham Dumpleton wrote:
My memory is that truss allows you to specify certain system
functions which you want verbose display of arguments and return
On 24/03/15 04:35, Graham Dumpleton wrote:
Am wondering whether relates to IOV_MAX being quite low on Solaris (16).
I perhaps was assuming the APR would deal with any limit and break it up
into separate calls as generally APR is good at papering over OS
differences. Checking apr_socket_sendv()
On 24/03/15 05:03, Graham Dumpleton wrote:
I only started using writev in that way in version 4.4.0 I think. Am out at
moment so can't check.
Will you take care of this?. I am not in a hurry to upgrade. 3.5 is fine
so far.
Looks like using writev to avoid overhead is going to add syscall
On 24/03/15 08:51, Graham Dumpleton wrote:
Can you try with:
https://github.com/GrahamDumpleton/mod_wsgi/archive/develop.tar.gz
and at least verify that it now works in daemon mode on Solaris.
Graham, I confirm than 4.4.11 is working correctly under Solaris 10.
Sorry for the long
Sending copy to the mod_wsgi mailing list, to summarize the thread.
On 04/12/15 03:58, Paul Kehrer wrote:
> Can you reproduce this if you set:
>
> WSGIApplicationGroup %{GLOBAL}
>
> ?
>
> We're aware of a current issue with lock and library initialization
> related to Python subinterpreters
On 03/12/15 18:04, Jason Garber wrote:
> Do you need to stream your response or can you just buffer it and return
> a list of bytes as the iterator?
I need to stream. The output can be unbounded. In fact, this is a
streaming service.
--
Jesús Cea Avión _/_/ _/_/_/
I have a mod_wsgi script that (tries to) create internally a TLS
connection to fetch data in order to fulfill the original HTTPS request.
Everything works when the connection my wsgi script creates is a plain
TCP/IP, but when I try to create a TLS connection my process get stuck
in this Python
I have an Apache virtualhost configured as a webdav server, but mapping
a certain subdirectory to mod_wsgi. My python code gets executed for
"GET" and "HEAD" requests, but "OPTIONS" and "PROPFIND" seems to be
captured and processed by the Apache core.
Is there any way for mod_wsgi to get all HTTP
On 01/09/15 01:56, Jason Garber wrote:
> Hi Graham,
>
> Are you aware of any reason mod_wsgi will not be compatible with Python
> 3.5 out of the gate next month?
I am using Python 3.5 in WSGI in production. No issues.
--
Jesús Cea Avión _/_/ _/_/_/_/_/_/
On 03/12/15 19:00, Jason Garber wrote:
> May be a dumb question but can you create the connection before the
> iterator and then read from it within?
No, because the connection can die/timeout/load balance/whatever anytime
and you need to open it again.
Anyway I am not concerned about how to
On 03/12/15 19:28, Jesus Cea wrote:
> It could happens that I finally move all the project to a standalone
> webserver instead of a wsgi application, for several reasons (paying a
> price I would rather not pay) but, in any case, this issue is something
> to investigate and solve
Context for "Cryptography" people:
Using "cryptography" and then trying to create a "ssl.SSLContext()"
hangs the progress when running under mod_wsgi. I can not reproduce this
issue with a standalone script, it must be run inside mod_wsgi. May be
useful to know that, in daemon mode, mod_wsgi uses
I think that current MOD_WSGI can only implement HEAD, GET, PUT methods,
but CAN NOT implement OPTIONS or PROPFIND. At least, I am not able to
get my code called when my client invoke those HTTP verbs.
Am I in an error?.
(See my message to the mailing list sent the 3th of December).
--
Jesús
On 17/01/18 15:00, Graham Dumpleton wrote:
>> """ if (!PyErr_Occurred() && !aborted) { if (Adapter_output(self,
>> "", 0, NULL, 0)) self->result = OK; } """
>>
>> I am not sure why "Adapter_output()" is called with NOOP operation
>> (maybe to signal "end of stream", but then I don't know why it
On 16/01/18 18:13, Jesus Cea wrote:
> Thanks for your time, Graham. Much appreciated.
Reading source code, I see things I don't understand and could be the issue:
When a request is processed, if it preemptively marked as "error 500".
This code will be changed to the right res
On 18/01/18 06:23, Graham Dumpleton wrote:
> Actually, it is also possible that it is ensuring headers are flushed
> out when there was no response content.
We have a mistery!. That line deserves a comment in the code :).
My issue is WHY is that done ONLY when no Python exception ocurred. I
Using Apache 2.4.29, mod_wsgi 4.5.24 and Python 3.6.4.
I serve big files using WSGI and an iterator. When the client closes the
connection BEFORE the file is completed, an error 500 is logged in
Apache, without any indication of the issue or how to solve it.
I have a minimal testcase:
1. Apache
On 16/01/18 10:46, Graham Dumpleton wrote:
> The access log is updated by the Apache child worker process that for
> daemon mode is proxying the connection to the actual process running
> your application. In this case where the client drops the connection
> before a complete response could be
On 16/01/18 13:58, Graham Dumpleton wrote:
> Thanks for letting me know.
>
> Not sure why it seems I never responded at the time. I suspect I may have
> been overseas start of Dec 2015, but still no excuse. :-)
I am always amazed by your responses in this group. Getting the usually
"bull-eyed"
On 21/01/18 03:02, Graham Dumpleton wrote:
> Try mod_wsgi from develop branch of Git repository with my changes.
>
> https://github.com/GrahamDumpleton/mod_wsgi/commit/004ae44ae46b410f3999da1a34dd11e469d98169
Testing
On 03/12/15 16:40, Jesus Cea wrote:
> I have an Apache virtualhost configured as a webdav server, but mapping
> a certain subdirectory to mod_wsgi. My python code gets executed for
> "GET" and "HEAD" requests, but "OPTIONS" and "PROPFIND" seems
On 24/01/18 19:45, Jesus Cea wrote:
> Testing
> <https://github.com/GrahamDumpleton/mod_wsgi/archive/004ae44ae46b410f3999da1a34dd11e469d98169.zip>.
Everything good after more than 24 hours of testing a quite a few HTTP
requests. Thanks.
--
Jes
On 08/02/18 02:39, Graham Dumpleton wrote:
> What are you setting the thread name too?
Beside the mod_wsgi threads running "application()", my code creates
tons of long term threads like "cache_cleanup",
"periodic_cache_flush_to_disk", "map generation workers", "audio
transcoding", etc.
>
On 07/02/18 06:10, Graham Dumpleton wrote:
> Fixed in:
>
> https://github.com/GrahamDumpleton/mod_wsgi/commit/f635d7f76380e9826b35d9d3ef09c2176a3e14d8
Cool. It works nicely.
Another request: When the Threads tracebacks are being dumped, please
use "thread.name" if available. I annotate my
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
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
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
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
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
33 matches
Mail list logo
