Looks like some tests are failing to mod_perl itself. Obviously, the
environment is the same as before and I am attaching the stderr. Any
help appreciated.
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/usr/local/apache2/build/mod_perl-2.0.2/t/TEST -verbose 't/ap
Hello,
I'm wondering if some other people here have some wisdom about this case
a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
"server side prepares", which is supposed to give a significant
performance boost in so
Jonathan Vanasco <[EMAIL PROTECTED]> [04-08-2006 18:07]:
[ ... context: storing client's IP in the
session and checking if it's the same ]
> internally, my ip doesn't change- and lengty connections are fine.
> but every new request goes through a different transparent proxy (
> dialup109.aol.com
Hello,
The mod_perl 2.0 User's Guide in its Section 7.10.1 "Thread Environment Issues,"
states "Operations that involve system calls, may or may not be thread-safe."
We have a handful of cgi scripts that need to put out a system call to run a
custom-built crc calculation routine. We're obviously
On Aug 5, 2006, at 6:07 AM, Radoslaw Zielinski wrote:
Thanks for explaining, I wasn't aware of cases like this. For some
reason, I thought you mean clients on some crazy PPP link which breaks
once every few minutes.
yeah, its extremely common with ISPs in the US.
its also common with busine
this is more of a discussion post than a response:
On Aug 5, 2006, at 10:02 AM, Mark Stosberg wrote:
do you have links of that in regards to dbd::pg? i didn't realize
they supported it.
However, when deploying it on mod_perl on a busy website, I quickly
saw a lot of this kind of error:
Mark Stosberg wrote:
Hello,
I'm wondering if some other people here have some wisdom about this case
a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
"server side prepares", which is supposed to give a significant
David Dick wrote:
Mark Stosberg wrote:
Hello,
I'm wondering if some other people here have some wisdom about this
case a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
"server side prepares", which is supposed
> t/api/status.t62 33.33% 4-5
> t/apache/content_length_header.t 271 3.70% 17
> Failed 1/1 test scripts, 0.00% okay. 1/27 subtests failed, 96.30% okay.
These have been fixed in SVN for quite some time. Please see the archives of
this list.
This is not a
On Sat, 2006-08-05 at 09:02 -0500, Mark Stosberg wrote:
> However, when deploying it on mod_perl on a busy website, I quickly saw
> a lot of this kind of error:
>
> prepared statement "dbdpg_7" already exists
Do you use prepare_cached? You might want to try that, with a 3 for the
$if_active par
Hi,
Considering that I can't use the current stable version of mod_perl
and libapreq, I am wondering if anyone could point me to an older (not
1.x though), "really" stable, bullet proof release that I could use in
the meantime (while the smart people are fixing the current release).
Many thanks
On Aug 5, 2006, at 6:14 PM, Arshavir Grigorian wrote:
Hi,
Considering that I can't use the current stable version of mod_perl
and libapreq, I am wondering if anyone could point me to an older (not
1.x though), "really" stable, bullet proof release that I could use in
the meantime (while the sm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Newer versions of DBD::Pg and PostgreSQL support a feature called
> "server side prepares", which is supposed to give a significant
> performance boost in some cases.
>
> However, when deploying it on mod_perl on a busy website, I quickly saw
> a l
Perrin Harkins wrote:
On Sat, 2006-08-05 at 09:02 -0500, Mark Stosberg wrote:
However, when deploying it on mod_perl on a busy website, I quickly saw
a lot of this kind of error:
prepared statement "dbdpg_7" already exists
Do you use prepare_cached? You might want to try that, with a 3 for
I found a related mention of this issue here:
http://fudforum.org/forum/index.php?t=msg&th=4598&start=0&;
There the fix involved putting using DEALLOCATE when persistent
first, the patch with DEALLOCATE makes prepared statements entirely
useless, as it means you're caching a prepared statement
I'm running:
apache 2.0.59
mod_perl 2.0.2
libapreq2 2.07
No problems. Apache 2.0.59 is pretty recent, but I've had no trouble
with previous versions of Apache either (2.0.58, etc).
Regards,
.lzs
--
http://thinkingfarm.com/~lzs/
Arshavir Grigorian wrote:
> Hi,
>
> Considering that I can't use
16 matches
Mail list logo
