Josh Lavin wrote:
On Dec 11, 2006, at 12:42 PM, Ron Phipps wrote:Josh Lavin wrote:On Dec 11, 2006, at 12:02 PM, Grant wrote:I've been seeing this too, on my Apache 2 and latest Link.pm. I also had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. The visible effect on the browser is that the page or image (which Link.pm apparently still has some part in delivering) does not load. I get them myself when browsing and testing my websites, and I have never stopped loading a page or had any other problems on non-IC sites I host. I was told the problem stems from either the browser and a stop button or some other network fault. I may go back to Apache 1.3 to get around this.> Hello, I've been plagued by apache2 segfaults ever since I started > using Interchange::Link years ago. The latest Link.pm has ALERT > messages accompanying the segfaults in error_log: > > ALERT: bad pipe signal received for /page.html > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal > Segmentation fault (11) >> Does anyone have any advice on solving this? I'm using apache-2.0.58> and mod_perl-2.0.2 in Gentoo Linux.Also, here is the portion of Link.pm that the ALERT seems to come from:# Return this message to the browser when the server is not running. # Log an error log entry if set to notify sub die_page { my $r = shift; my $msg; warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n"; $r->content_type ("text/html"); $r->print (<<EOF); <HTML><HEAD><TITLE>Interrupted</TITLE></HEAD> <BODY BGCOLOR="#FFFFFF"> <H3>Someone pressed stop...</H3> <P> We have aborted this request because someone terminated it. Please try again soon. </BODY></HTML> EOF } Please let me know if you have any ideas.The segfaults are eliminated by commenting out the $r stuff in the die_page sub. I still get the ALERTs though. Does anyone have any advice on figuring out why I'm having the bad pipe problem? Is there an easy way to add extra debugging info to the sub?Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs 50 fold.I saw this occur on two different installations about 4 months ago. It was suggested that I abandon the use of Link.pm and go back to using the cgi method with URL rewrite rules as this was just as fast and proved stable over the years.Is plain CGI really as fast as mod_perl or mod_interchange? That'd be my only concern with switching back to CGI+rewrites.Maybe it is ok -- see mod_interchange's README: "The Interchange link protocol has been implemented via an Apache module which saves us the (small) overhead of the execution of a CGI program."
Josh, I have not done any a/b tests to determine which is faster, others have. Vlink/tlink is currently being used without any speed issues during high traffic periods at: www.bcstore.com www.frozencpu.com www.citypass.com www.reliablemedical.com Quite a bit of time was put in with BCStore to compare which method was stable and fast and it was determined that tlink/vlink was the way to go. I thought that we needed to use mod_interchange/mod_perl for FrozenCPU, but quickly found out that under Apache 2.0/mod_perl the issues far outweighed any perceived speed up. tlink/vlink are compiled c programs and should be very quick in execution. At End Point we use rewrites with tlink/vlink pretty much exclusively. Thanks, -- Ron Phipps End Point Corporation suppressed _______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.