On Thu, 3 Jan 2002, Rodent of Unusual Size wrote:
> Stas Bekman wrote:
> >
> > Found the problem, temporary replace
> >
> > $child_pid = open $child_in_pipe, "|$cmd";
> >
> > with:
> >
> > system "$cmd &";
> >
> > in Apache-Test/lib/Apache/TestServer.pm
>
> Thanks, I'll try that..
>
> > Any
On Fri, 4 Jan 2002, Stas Bekman wrote:
> Found the problem, temporary replace
>
> $child_pid = open $child_in_pipe, "|$cmd";
>
> with:
>
> system "$cmd &";
>
> in Apache-Test/lib/Apache/TestServer.pm
>
> the way it was before (well sort of, it's not good in failure cases, but
> at least it s
On Thu, Jan 03, 2002 at 06:56:16AM -0800, Aaron Bannert wrote:
> There's some good info on this site for developers: http://dev.apache.org/
> You'll be particular interested in: http://dev.apache.org/patches.html
FWIW, please point people at:
http://www.apache.org/dev/
http://httpd.apache.org/dev
Stas Bekman wrote:
>
> Found the problem, temporary replace
>
> $child_pid = open $child_in_pipe, "|$cmd";
>
> with:
>
> system "$cmd &";
>
> in Apache-Test/lib/Apache/TestServer.pm
Thanks, I'll try that..
> Any ideas why this doesn't work with 1.3? Something goes wrong
> with the spawned pr
Found the problem, temporary replace
$child_pid = open $child_in_pipe, "|$cmd";
with:
system "$cmd &";
in Apache-Test/lib/Apache/TestServer.pm
the way it was before (well sort of, it's not good in failure cases, but
at least it starts)
this is because of my latest patch to make t/TEST immediately
Stas Bekman wrote:
>
> it says that the code hangs on line 570 in
> Apache-Test/lib/Apache/TestRun.pm. But sometimes compiler get confused
> by a few lines, so I'm not sure where exactly the problem is. Can you
> please check if it hangs after $self->start()? e.g. add die() after it:
>
> $se
I've been thinking about how to handle data lifetime scoping in
flood and have come up with a solution, but I want some feedback
before I jump in and do it.
Theoretically, one instance of flood might need data that is scoped
at each of the following lifetimes:
all farms
each farm
all farmers
each
On Thu, Jan 03, 2002 at 10:02:31AM -0500, Chris Williams wrote:
> Yes it is. I will review those links for the next time.
Cool, I'll test and commit. Keep 'em comming! :)
-aaron
Yes it is. I will review those links for the next time.
Thanks!
Chris
> -Original Message-
> From: Aaron Bannert [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 03, 2002 9:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Cookie Patch for Flood
>
>
> On Thu, Jan 03, 2002 at 09:43:48AM -050
On Thu, Jan 03, 2002 at 09:43:48AM -0500, Chris Williams wrote:
> I found a bug in flood_round_robin.c. The apr_pstrcat on line 146 should
> have NULL as the last argument. I am new to submitting patches so if
> someone could let me know the correct way to do it, I will repost. Without
> this, y
I found a bug in flood_round_robin.c. The apr_pstrcat on line 146 should
have NULL as the last argument. I am new to submitting patches so if
someone could let me know the correct way to do it, I will repost. Without
this, you get a bunch of garbage in the cookie string if there is more that
one
Rodent of Unusual Size wrote:
* On 2002-01-03 at 08:07,
Stas Bekman <[EMAIL PROTECTED]> excited the electrons to say:
Whenever you have a hanging problem in Perl, the solution is very
simple. Put into your code this:
:
and then kill the process with:
% kill -USR2 PID
And the printed tra
Rodent of Unusual Size wrote:
* On 2002-01-03 at 08:07,
William A. Rowe, Jr. <[EMAIL PROTECTED]> excited the electrons to say:
t/TEST -d=lwp 2
should show you where things stall, in a bit more detail.
Tried that, not very revealing; it just shows the GET of /index.html
after the fragment of outpu
* On 2002-01-03 at 08:07,
Stas Bekman <[EMAIL PROTECTED]> excited the electrons to say:
>
> Whenever you have a hanging problem in Perl, the solution is very
> simple. Put into your code this:
:
> and then kill the process with:
>
> % kill -USR2 PID
>
> And the printed trace will tell
* On 2002-01-03 at 08:07,
William A. Rowe, Jr. <[EMAIL PROTECTED]> excited the electrons to say:
>
> t/TEST -d=lwp 2
>
> should show you where things stall, in a bit more detail.
Tried that, not very revealing; it just shows the GET of /index.html
after the fragment of output I reported earlie
On Thu, 3 Jan 2002, Stas Bekman wrote:
> Rodent of Unusual Size wrote:
>
> > Was this feedback useful, Stas?
>
> Yes, yes. I can reproduce the problem. The respawned shell to set the
> ulimit loses the return status. I'm looking into it. It's a nasty one.
OK, Ken, please try this patch. If it wor
Rodent of Unusual Size wrote:
Was this feedback useful, Stas?
Yes, yes. I can reproduce the problem. The respawned shell to set the
ulimit loses the return status. I'm looking into it. It's a nasty one.
_
Stas Bekman
Sorry I'm not using that bug_report.pl (or whatever it
was) script, Stas, but it doesn't appear to be part of
the httpd-test repository. Apologies also for not being
much help in debugging these things, but I just can't
trace my way through the Deep Magic variety of Perl
used here..
It's moved. N
From: "Rodent of Unusual Size" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 10:47 PM
> Maybe it's because of all the attention on 2.0, but suddenly
> t/TEST is hanging when run against a 1.3 server. This is
> new behaviour since 2 December 2001, when it was working
> fine.
t/TEST -d=lw
Maybe it's because of all the attention on 2.0, but suddenly
t/TEST is hanging when run against a 1.3 server. This is
new behaviour since 2 December 2001, when it was working
fine.
What I get now is:
% t/TEST
setting ulimit to allow core files
ulimit -c unlimited
exec t/TEST -v apache/etags
/tm
I've been diagnosing our failures of httpd.
My Win32 machine has the usual, bogus computer name (v505, in my case.)
There is no 'magic' DNS going on, Win32 is usually clueless. And since
I cannot convice my machine to look in any DNS other than the 'blessed
Windows Domain Server' [I have none], I
21 matches
Mail list logo
