[OGo-Developer] Bugs in mod_ngobjweb

[Sebastian Reitenbach]

developer@opengroupware.org wrote: 
> Hi,
> 
> I'm getting more and more confused :-(
> 
> On Mar 27, 2008, at 10:15 AM, Helge Hess wrote:
> 
> > On 27.03.2008, at 09:49, St=E9phane Corth=E9sy wrote:
> >> Does this mean that mod_ngobjweb does not support file upload?
> >
> > Sure it does (and its used that way a lot in OGo, not exactly sure  
> > why you are experiencing issues).
> 
> 
> OK, so that's good news.
> Precisely, I used WOFileUpload, and mod_ngobjweb on apache 2.2.6/OSX  
> 10.5.2 Server. Most of the time users can't upload files with Safari;  
repeating the operation with the same file always fails: Safari sends  file, 
and waits forever.
> I noticed the httpd crashed sometimes, in mod_ngobjweb code, or,  
> worse, becomes completely crazy and eats all memory and CPU!
I've seen httpd crashes too, but I am not sure, whether they happen in the 
mod_ngobjweb module. I've also seen apache eating all CPU and Memory.
I'm on sles10sp1 x86_64, with ogo/mod_ngobjweb installed as 64Bit versions.

But I am still unable to reproduce the issue, as they seem to 
happen "randomly". Most of the users use Konqueror, or Firefox.

But if I remember correctly, many of these eating all CPU/Memory happens 
when uploading files or mail attachements.

Just my observations
Sebastian

> The same files passed via Firefox work. I don't know whether it's  
> 100% success, though.
> 
> 
> >> I know very little about apache, bear with me.
> >> Currently I have this config:
> >
> > Hm, no, you either use mod_ngobjweb OR mod_proxy :-)
> >
> >
> > OK, back to the start ;-) What is mod_ngobjweb. Its
> > a) a non-streaming proxy
> > b) a protocol downgrader
> > c) a load balancer which works in combination with snsd
> > You usually don't care about c).
> >
> > a) means that mod_ngobjweb collects the whole HTTP requests sent by  > 
the browser before it transfers it to the SOPE application. This  
> > removes the browser<->WAN<->Server latency/slowness towards the  
> > app. Which is important because the SOPE app is non-threaded (and  
> > doesn't use non-blocking-IO for reading requests), hence it should  
> > not block on IO.
> >
> > b) is basically the reason why you could not use Apache mod_proxy  
> > as a SOPE frontend, even if you don't care about issue a). SOPE  
> > applications are not fully conforming HTTP servers, especially not  
> > HTTP/1.1 ones. Therefore Apache is used in front, which does all  
> > the HTTP heavy-lifting. mod_ngobjweb then talks HTTP/1.0 w/o  
> > keepalive etc to the SOPE app.
> > Now the new thing (and that was my comment in the last mail) is,  
> > that mod_proxy can now also do the downgrade for 'b0rked' HTTP  
> > backend servers.
> >
> > Why would you want to use mod_proxy. Well, it comes preinstalled  
> > with every Apache and its of course much more stable :-)
> > Not sure yet how to resolve a) though.
> 
> 
> Question is: would it work to use mod_proxy?
> 
> > Summary for you: you probably want to ignore all that and continue  
> > fixing your specific mod_ngobjweb problem :-)
> 
> 
> Hhm, well... Any clue on what's wrong with the module?
> 
> Here's the latest crash (this morning); module had the fixes I sent you.
> 
> Thread 0 Crashed:
> 0   libaprutil-1.0.dylib                0x00069218 apr_brigade_create  + 
42
> 1   httpd                               0x0002dcdd  
> ap_get_client_block + 98
> 2   mod_ngobjweb.so                     0x003b1a77 _readRequestBody +  269
> 3   mod_ngobjweb.so                     0x003b230c ngobjweb_handler +  502
> 4   httpd                               0x00002182 ap_run_handler + 70
> 5   httpd                               0x000028cf ap_invoke_handler  
> + 316
> 6   httpd                               0x0002a4e0 ap_process_request  + 
101
> 7   httpd                               0x00026eb6  
> ap_process_http_connection + 113
> 8   httpd                               0x00011055  
> ap_run_process_connection + 70
> 9   httpd                               0x0001146f  
> ap_process_connection + 81
> 10  httpd                               0x000308c6 child_main + 1169
> 11  httpd                               0x00030aae make_child + 384
> 12  httpd                               0x00030d11  
> perform_idle_server_maintenance + 480
> 13  httpd                               0x0003125d ap_mpm_run + 1285
> 14  httpd                               0x0000962b main + 2969
> 15  httpd                               0x000018f6 start + 54
> 
> 
> St=E9phane
> 
> 
> > Greets,
> >   Helge
> > -- 
> > Helge Hess
> > http://www.helgehess.eu/--
> > OpenGroupware.org Developer
> > developer@opengroupware.org
> > http://mail.opengroupware.org/mailman/listinfo/developer
> 
> -- 
> OpenGroupware.org Developer
> developer@opengroupware.org
> http://mail.opengroupware.org/mailman/listinfo/developer
>