I am currently in the process of transferring a database driven site from
IIS to Apache on NT using mod_perl. Apache seems to lock up after about
10-20 minutes and the only way to get things going again is to restart
Apache (Apache is running from the console not as a service).
The site isn't
Gerald Richter wrote:
I have seen this in the source too, that's why I wrote it will not work with
Apache, because most pages will be greater the 8K. Patching Apache, is one
possibility, that's right, but I just looked after the
ProxyReceiveBufferSize which Oleg pointed to, and this one
i am trying to read the headers of an incoming HTTP request
in a CGI script. It seems to me that the only way to do so is
to use mod_perl methods since the standard CGI interface does not
provide request header access - or am I missing something here?
The problem is that in this specific
I am currently in the process of transferring a database driven site from
IIS to Apache on NT using mod_perl. Apache seems to lock up after about
10-20 minutes and the only way to get things going again is to restart
Apache (Apache is running from the console not as a service).
Well - I am
At 12:20 PM 1/17/00 +0100, Waldek Grudzien wrote:
I am currently in the process of transferring a database driven site from
IIS to Apache on NT using mod_perl. Apache seems to lock up after about
10-20 minutes and the only way to get things going again is to restart
Apache (Apache is running
I have just gone back and checked the logs. The majority of the time the
server locks up without putting anything in the error log. Currently,
there are only about 10 content handlers in the system and I am fairly
confident they work.
When it locks up I can still telnet into the server
On Mon, 17 Jan 2000, Gerald Richter wrote:
Look at proxy_http.c line 263 (Apache 1.3.9):
if (setsockopt(sock, SOL_SOCKET, SO_RCVBUF,
(const char *) conf-recv_buffer_size, sizeof(int))
I am not an expert in socket programming, but the setsockopt man page on my
At 01:26 PM 1/17/00 +0100, Gerald Richter wrote:
I would suggest, put
warn "foo" ;
allover in your perl code and then look in the error log and see where the
last warn came from, then you have the place where it lock up.
Gerald
I added the warns to the scripts and it appears that access to
On Sun, 16 Jan 2000, DeWitt Clinton wrote:
[...]
On that topic, is there an alternative to squid? We are using it
exclusively as an accelerator, and don't need 90% of it's admittedly
impressive functionality. Is there anything designed exclusively for this
purpose?
At ValueClick we can't
Hi there,
On Mon, 17 Jan 2000, Joshua Chamas wrote:
On Solaris, default seems to be 256K ...
As I remember, that's what Linux defalts to. Don't take may word for
it, I can't remember exactly where or when I read it - but I think it
was in this List some time during the last couple of months!
I added the warns to the scripts and it appears that access to the modules
is serialised. Each call to the handler has to run to completion before
any other handlers can execute.
Yes, on NT all accesses to the perl part are serialized. This will not
change before mod_perl 2.0
Gerald
I had
An Englishman asked an Irishman for directions to a place some
distance away. The Irishman replied, "T'be sure, if oi was going
there, oi wouldn't start from here!".
This *is* a bit off-topic, but the guy needs help.
Ged, this is a wonderful thing that you do.
But, if you help someone
The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if
the client breaks the connection.
Is there a recommendation on how to catch stop run away mod_perl programs
in a way that's _not_ part of the run away program. Or is this even
possible? Some type of watchdog, just like
Hi there,
On Mon, 17 Jan 2000, Ask Bjoern Hansen wrote:
At ValueClick we can't use the caching for obvious reasons so we're using
a bunch of apache/mod_proxy processes in front of the apache/mod_perl
processes to save memory.
Even with our average 1KB per request we can keep hundreds of
The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if
the client breaks the connection.
Is there a recommendation on how to catch stop run away mod_perl programs
in a way that's _not_ part of the run away program. Or is this even
possible? Some type of watchdog, just
So, if you want to increase RCVBUF size above 65535, the default max
value, you have to raise first the absolut limit in
/proc/sys/net/core/rmem_max,
Is "echo 131072 /proc/sys/net/core/rmem_max" the proper way to do this? I don't have
much experience with /proc, but this seems to work. If
so i am just wanting to know what anyone
has found out on mod perl not working properly
under redhat 6.1?
thanks
At 06:48 PM 1/17/00 +0200, Stas Bekman wrote:
The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if
the client breaks the connection.
Is there a recommendation on how to catch stop run away mod_perl programs
in a way that's _not_ part of the run away program. Or is
Clay wrote:
so i am just wanting to know what anyone
has found out on mod perl not working properly
under redhat 6.1?
If you install everything (including modperl) from RedHat's RPMs, no problem (I
did this on five very different boxes, some new, some upgraded). If you try to
do it yourself
no, i have only used the redhat packages, i have extensivley search all
related new s groups etc,
the startup file ive incl'd has been the one ive borrowed from the mod perl
book or the guide online,
i have never had problems up until redhat 6.1 {stampede slak and redhat 6
all worked fine}
i
I have had the same exprience as Stas.
The Red Hat RPM uses Dynamic Shared Objects (DSO) for all the
modules. This is NOT the ideal way to run mod_perl, I am not saying
you can't, but a lot of modules won't preload under these conditions.
my $.02
Aaron Johnson
Stas Bekman wrote:
Clay
On Mon, 17 Jan 2000, Markus Wichitill wrote:
So, if you want to increase RCVBUF size above 65535, the default max
value, you have to raise first the absolut limit in
/proc/sys/net/core/rmem_max,
Is "echo 131072 /proc/sys/net/core/rmem_max" the proper way to do
this? I don't
Hi all,
On Mon, 17 Jan 2000, Stas Bekman wrote:
Please try to keep it clean and not encourage off-topic questions.
Sorry, Stas, you're quite right. I often do reply privately to the
off-topic questions, and I suppose even that might be construed as
encouraging them. I do however also try
I seem to be having problems with Red Hat 6.1 mod_perl. Compiled and
installed from scratch. This is an out-of-the box Penguin Computer running
RH6.1.
The strange behavior that manifests itself as follows:
Config 1
Location /server-status
SetHandler server-status
On Mon, 17 Jan 2000, G.W. Haywood wrote:
At ValueClick we can't use the caching for obvious reasons so we're using
a bunch of apache/mod_proxy processes in front of the apache/mod_perl
processes to save memory.
Even with our average 1KB per request we can keep hundreds of mod_proxy
No, that's the size of the system call buffer. It is not an
application buffer.
So how one should interpret the info at:
http://www.apache.org/docs/mod/mod_proxy.html#proxyreceivebuffersize
QUOTE
The ProxyReceiveBufferSize directive specifies an explicit network buffer
size
Clay,
Well I agree after seeing your startup.pl that the problem you are
expriencing is not with the DSO, however from past posts with problems
there are several modules that do not play well with DSO.
However as far as any problem with using the Red Hat distributed RPM
of Apache and mod_perl
Hi again, folks,
Last Saturday after manually relinking SDBM_File with a reference to
mod_perl libperl.so, I was able to preload Apache::ASP and precompile the
asp scripts from startup.pl without any segfaults. This however, resulted
in a different problem. I didn't notice it right away
Dmitry Beransky wrote:
Hi again, folks,
Last Saturday after manually relinking SDBM_File with a reference to
mod_perl libperl.so, I was able to preload Apache::ASP and precompile the
asp scripts from startup.pl without any segfaults. This however, resulted
in a different problem. I
Hi Stas,
Yes, as Joshua posted today morning (at least it was morning in
germany :-),
the application buffer size is hardcoded, the size is 8192 (named
IOBUFSIZE). You will find it in proxy_util.c:ap_proxy_send_fb().
The ProxyReceiveBufferSize set the receive buffer size of the
Yes, as Joshua posted today morning (at least it was morning in
germany :-),
the application buffer size is hardcoded, the size is 8192 (named
IOBUFSIZE). You will find it in proxy_util.c:ap_proxy_send_fb().
The ProxyReceiveBufferSize set the receive buffer size of the socket, so
On Sun, 16 Jan 2000, Alan Burlison wrote:
I think we have a strong case for:
a) Requesting that MakeMaker adds a dependency between the .so files it
generates and the perl libperl.so
b) Requesting that a 'remove a module' method is added to DynaLoader
Option b would be very useful for
32 matches
Mail list logo
