Quoting Wiebe Kloosterman <[EMAIL PROTECTED]>:
> i have set "PerlSetVar ntlmsemtimout" but no change in syslog for timeout.
hmmm... Maybe I need a bit more information about the problem that you are
having. The logs point to a problem with a timeout that is put into place to
keep multiple auth
I would second Perrin's comment, why use ithreads instead of forking and
perhaps some socket communication. I've tested both fork and threads in a
high performance envorinment, and fork is simply the better choice as
long as lines of code is not your judgement criteria.
Best,
Tom
Thomas S. Br
On Dec 30, 2003, at 8:21 AM, Geoffrey Young wrote:
but the connection cache mechanism has always seemed rather funky -
when we
were writing about Apache::DBI for the cookbook, I remember some issues
between Win32 and linux that randy and I were having when it came to
emulating the connect-string
I finally got around to assemble most of the patches sent in the last
few months and make a new package:
http://develooper.com/code/Apache::DBI/Apache-DBI-0.93.tar.gz
Unless anyone finds a critical error in the next few days then I'm
going to upload it to CPAN.
Changes since 0.92:
0.93Ja
steve larson wrote:
Hello,
-8<-- Start Bug Report
8<--
1. Problem Description:
It appears, it is still finding a 1.3 Apache install
somewhere, and is using this binary, as I have totally
renamed /etc/httpd and re-linked this to a directory
where the Apache
At 13:26 -0800 1/9/04, Stas Bekman wrote:
Elizabeth Mattijsen wrote:
I'm sure you know my PerlMonks article "Things yuu need to know
before programming Perl ithreads" (
http://www.perlmonks.org/index.pl?node_id=288022 ).
So yes, in general I think you can say that the data copied for
each thread, q
Hello,
-8<-- Start Bug Report
8<--
1. Problem Description:
It appears, it is still finding a 1.3 Apache install
somewhere, and is using this binary, as I have totally
renamed /etc/httpd and re-linked this to a directory
where the Apache 2.x exists: ie. /us
I don't know if this is possible or not, but I took parts of DBILogger and wanted to
extend what I could
do with it. What I would like to do is for a given request to a cgi program (or
mason) if the script causes
an internal error (which should not happen in production, but does) I would like to
Elizabeth Mattijsen wrote:
At 15:17 -0500 1/9/04, Perrin Harkins wrote:
On Fri, 2004-01-09 at 14:52, Stas Bekman wrote:
We really need more real world benchmarks to make a good judgement.
It's
probably quite certain that the performance is going to be worse if
you spawn
threads, but don't de
On Fri, 2004-01-09 at 16:02, Elizabeth Mattijsen wrote:
> You mean a rewrite of the article? Or more a bullet list of things?
I was thinking of something that briefly makes these points:
- Threads have a higher startup cost.
- Perl is slower when built with threads.
- Threads tend to use more me
At 15:51 -0500 1/9/04, Perrin Harkins wrote:
On Fri, 2004-01-09 at 15:34, Elizabeth Mattijsen wrote:
So yes, in general I think you can say that the data copied for each
thread, quickly dwarves whatever optrees are shared.
Thanks Liz, this is useful data. Maybe we should add something to the
mod
On Fri, 2004-01-09 at 15:34, Elizabeth Mattijsen wrote:
> So yes, in general I think you can say that the data copied for each
> thread, quickly dwarves whatever optrees are shared.
Thanks Liz, this is useful data. Maybe we should add something to the
mod_perl 2 docs that summarizes the current
Perrin Harkins wrote:
On Fri, 2004-01-09 at 14:52, Stas Bekman wrote:
We really need more real world benchmarks to make a good judgement. It's
probably quite certain that the performance is going to be worse if you spawn
threads, but don't deploy the benefits available exclusively to threads
(s
At 15:17 -0500 1/9/04, Perrin Harkins wrote:
On Fri, 2004-01-09 at 14:52, Stas Bekman wrote:
We really need more real world benchmarks to make a good judgement. It's
probably quite certain that the performance is going to be worse
if you spawn
threads, but don't deploy the benefits available ex
On Fri, 2004-01-09 at 14:52, Stas Bekman wrote:
> We really need more real world benchmarks to make a good judgement. It's
> probably quite certain that the performance is going to be worse if you spawn
> threads, but don't deploy the benefits available exclusively to threads
> (shared opcode tr
At 19:36 + 1/9/04, Simon Clewer wrote:
For us the point of ithreads is that you don't have to mess about passing
messages or whatever - all those problems have been solved by the dudes who
wrote the threading module and you and they have given you shared variables
for your convenience.
I h
Hi!
Sorry for not getting back sooner!! We have been busy getting to know
our 2 month old baby :)
when i do change PerlSetVar ntlmdebug to 2 than i get this
[20641] AuthenNTLM: Config Domain = xxx pdc = XX100A bdc = XX0001
[20641] AuthenNTLM: Config Default Domain = XXX
[20641] AuthenNTLM: C
Perrin Harkins wrote:
On Fri, 2004-01-09 at 04:14, Stas Bekman wrote:
Ah, sorry for chiming in again, it's true regarding the memory, but not that
bad regarding performance. The only real performance overhead is to spawn a
new perl interpreter (which is just terrible if you have many modules
pr
Apologies folks, as Stas just pointed out, I was not replying to all
We thought that ithreads would be the ideal tool - should solve the issues
of processes communicating with each other for us, so that we don't have to.
Yes, (pre) forking would work and running a separate "server" to handle th
- Original Message -
From: "Simon Clewer" <[EMAIL PROTECTED]>
To: "Stas Bekman" <[EMAIL PROTECTED]>
Sent: Friday, January 09, 2004 11:11 AM
Subject: Re: ithreads with modperl
> In our case Stas is right, there's plenty of processor resources - even
> though the final request takes up to
Mathias Herberts wrote:
I solved my problem by adding a
PerlModule ..
directive in my Apache conf, but I saw nowhere in the documentation
about modules that this directive was needed, maybe this is something to
add to avoid repeating my problem.
You mean the filter wasn't loaded until secon
Mathias Herberts wrote:
Hi,
still in the process of building an Input Connection Filter I noticed
something wrong with all Connection Filter examples I could find
(including HTTPHeadersFixup), in case the connection is instructed to be
kept open with 'Connection: Keep-Alive', several requests w
On Fri, 2004-01-09 at 11:45, Perrin Harkins wrote:
> However, this is 5.6 with
> ithreads that we're talking about
Correction, Simon says they are actually using 5.8.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
On Fri, 2004-01-09 at 04:14, Stas Bekman wrote:
> Ah, sorry for chiming in again, it's true regarding the memory, but not that
> bad regarding performance. The only real performance overhead is to spawn a
> new perl interpreter (which is just terrible if you have many modules
> preloaded), which
>
> Scrooling back on the *stdout*, however, gives something that looks
> like what you want; could the test scaffold have gotten bollixed?
nope, that's where it's supposed to be.
anyway, I just tries to reproduce using 5.6.1, 1.99_12, and 2.0.48 and I can't.
here is a patch that will spit som
The uploaded file
Apache-AuthzPasswd-0.12.tar.gz
has entered CPAN as
file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthzPasswd-0.12.tar.gz
size: 4916 bytes
md5: cfa207588fb4b8d97147711aad23fffd
This is an announcement of the newest version of Apache-AuthzPasswd. This version has added:
1.
On 01/08/2004 10:14 PM, Perrin Harkins wrote:
On Thu, 2004-01-08 at 15:43, Alexander Bergolth wrote:
Why do I create a closure? If i'd create a closure I would have to store
a reference to an _anonymous sub
No, that's a common misconception. Closures and anonymous subs are two
totally separate t
Hi,
still in the process of building an Input Connection Filter I noticed
something wrong with all Connection Filter examples I could find
(including HTTPHeadersFixup), in case the connection is instructed to be
kept open with 'Connection: Keep-Alive', several requests will be run
through the
I solved my problem by adding a
PerlModule ..
directive in my Apache conf, but I saw nowhere in the documentation
about modules that this directive was needed, maybe this is something to
add to avoid repeating my problem.
Mathias Herberts wrote:
Hi,
I am writing an Input Connection Filter
Hi Simon,
Simon Clewer wrote
Hi,
We're using ithreads with modperl to run some complicated robots
concurrently ( in a commercial environment ) - there is however an issue.
Huge memory usage ... each ithread uses about 10M of ram ( image of Apache,
image of mod perl and image of our deep-link ro
Hi,
I am writing an Input Connection Filter for Apache 2.0.48 using mod_perl
1.99_12 to allow mod_dav to work behind a reverse proxy.
My filter works well except for the fact that it seems to miss a few
requests right after Apache startup. Has anybody else ever experienced
this behavior, and i
At 01:22 + 1/9/04, Simon Clewer wrote:
We are simply running out of memory, which is sad because we are nowhere
near running out of processor and it grieves me to simply use a bigger
server when it seems that smarter could solve the problem. Other than that
things are working very nicely and th
Hi there,
I'd echo what Perrin has said, but if only for the archives I need to ask:
On Fri, 9 Jan 2004, Simon Clewer wrote:
> [snip] we're using heaps of memory.
>
> Does anybody know how we can reduce the amount of memory we use ? - is there
> some smart way to actually share the images.
The
Joseph Turian wrote:
Fresh mod_perl 1.29 and apache-1.3.27 source fails on 'make' if, when
mod_perl is being configured, '--show-layout' is passed to Apache.
e.g. if I configure with:
perl Makefile.PL APACHE_SRC=../apache_1.3.27/ DO_HTTPD=1 USE_APACI=1
EVERYTHING=1 APACI_ARGS='--show-layout'
Then t
Perrin Harkins wrote:
On Thu, 2004-01-08 at 20:22, Simon Clewer wrote:
Huge memory usage ... each ithread uses about 10M of ram ( image of Apache,
image of mod perl and image of our deep-link robot ), and as we use 5
ithreads plus the original thread that means that each Apache is using 60 M
and
Perrin Harkins wrote:
On Thu, 2004-01-08 at 16:34, Stas Bekman wrote:
But since we expect most modules to run under any MPM, it usually applies to
any code.
Any code that you plan to release on CPAN, that is. It's still okay in
internal code when you know you won't be running threaded MPMs.
Yo
The usual drill. Don't complain if something goes wrong after 5.8.3 is
released. Test the release candidate with your code now.
++
| Perl 5.8.3 RC1 is out |
| posted by rafael on Thu
37 matches
Mail list logo
