Geoffrey Young wrote:
Stas Bekman wrote:
Geoff, any chance we can get this one resolved? As we may make a new
release soonish, we can't have this collision in Apache::compat and
APR::Finfo get out from the dev release.
I really don't know the answer to this. the new finfo API is a proper
interf
As our test suite grows it takes more and more time to start the server, the
worker mpm almost always fail to start within 60 secs on my machine (which is
pretty fast). And now we get reports from users who run prefork and it takes
68 secs to start.
So I'd suggest to make the default per server
>> I still think this is a solution worthy of investigation. I just
>> don't care
>> about 1) and I think we might be able to work around 2) somewhat - I've
>> created subclasses that return my own objects for $r->connection, so I
>> would
>> assume we can do the same for $r->server, $r->parsed_u
Stas Bekman wrote:
> As our test suite grows it takes more and more time to start the server,
> the worker mpm almost always fail to start within 60 secs on my machine
> (which is pretty fast). And now we get reports from users who run
> prefork and it takes 68 secs to start.
yikes. I got 49 se
On Tue, 2003-12-09 at 18:57, Stas Bekman wrote:
> Which probably means that your perl POSIX implementation is broken.
Wed Dec 10 12:15:18 [EMAIL PROTECTED]:~> su -
Password:
[EMAIL PROTECTED] root]# perl -le 'require POSIX; POSIX::setgid(99) or die
"failed to run: $@";'
[EMAIL PROTECTED] root]#
Geoffrey Young wrote:
Stas Bekman wrote:
As our test suite grows it takes more and more time to start the server,
the worker mpm almost always fail to start within 60 secs on my machine
(which is pretty fast). And now we get reports from users who run
prefork and it takes 68 secs to start.
yikes
> Of course. We have the new argument -startup_timeout (which is still
> misplaced), which we will set if it wasn't set already, just like
> maxclients.
actually, I no longer think it's misplaced - I want the persistence that
placing it where it is gives. that is, if I need to raise it for my
pa
Geoffrey Young wrote:
I still think this is a solution worthy of investigation. I just
don't care
about 1) and I think we might be able to work around 2) somewhat - I've
created subclasses that return my own objects for $r->connection, so I
would
assume we can do the same for $r->server, $r->parse
Geoffrey Young wrote:
Of course. We have the new argument -startup_timeout (which is still
misplaced), which we will set if it wasn't set already, just like
maxclients.
actually, I no longer think it's misplaced - I want the persistence that
placing it where it is gives. that is, if I need to ra
On Tue, 2003-12-09 at 17:44, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > It's been a long time that perl sections have been having trouble with
> > recursive inclusion. This has been discussed before and has to do with
> > the fact that all PerlSections are evaluated in the same namespace
On Wed, 2003-12-10 at 01:04, Stas Bekman wrote:
> As our test suite grows it takes more and more time to start the server, the
> worker mpm almost always fail to start within 60 secs on my machine (which is
> pretty fast). And now we get reports from users who run prefork and it takes
> 68 secs
>
> 2. Leave %Apache::ReadConfig:: alone until right after the config phase
> and feed it to Apache::PerlSections in one go
>
> Problem with this that processing of Apache::ReadConfig (for modules and
> code that push into it themselves) will be delayed at the very end and
> might break existing
Philippe M. Chiasson wrote:
On Tue, 2003-12-09 at 17:44, Stas Bekman wrote:
Philippe M. Chiasson wrote:
It's been a long time that perl sections have been having trouble with
recursive inclusion. This has been discussed before and has to do with
the fact that all PerlSections are evaluated in the
> Am I
> correct to say that people don't need to work directly with
> Apache::ReadConfig? I think the only place this is needed when people
> mix config with non-config perl code in , so that they need to
> switch 'package Apache::ReadConfig;' to start feeding things into the
> config.
no, you ca
Geoffrey Young wrote:
Am I
correct to say that people don't need to work directly with
Apache::ReadConfig? I think the only place this is needed when people
mix config with non-config perl code in , so that they need to
switch 'package Apache::ReadConfig;' to start feeding things into the
config.
>> it's similar to Apache->server->add_config() in mp2, but I've found that
>> method really not worth the trouble - it's goverened by overrides, so you
>> can never really trust that it will add the configuration data you
>> pipe into it.
>
>
> That's exactly why people do *not* need to work di
On Wed, 2003-12-10 at 11:49, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > On Tue, 2003-12-09 at 17:44, Stas Bekman wrote:
> >
> >>Philippe M. Chiasson wrote:
> >>
> >>>It's been a long time that perl sections have been having trouble with
> >>>recursive inclusion. This has been discussed b
On Wed, 2003-12-10 at 11:51, Geoffrey Young wrote:
> > Am I
> > correct to say that people don't need to work directly with
> > Apache::ReadConfig? I think the only place this is needed when people
> > mix config with non-config perl code in , so that they need to
> > switch 'package Apache::ReadCo
Geoffrey Young wrote:
it's similar to Apache->server->add_config() in mp2, but I've found that
method really not worth the trouble - it's goverened by overrides, so you
can never really trust that it will add the configuration data you
pipe into it.
That's exactly why people do *not* need to work
On Wed, 2003-12-10 at 12:06, Stas Bekman wrote:
> Geoffrey Young wrote:
> >>Am I
> >>correct to say that people don't need to work directly with
> >>Apache::ReadConfig? I think the only place this is needed when people
> >>mix config with non-config perl code in , so that they need to
> >>switch 'p
>> well, as I said, add_config() can't accomplish the same thing. in fact,
>> every time I've tried to use add_config() the way I want I haven't
>> been able
>> to. not that it's not useful for some things, but it's not useful for
>> the
>> level of trickery that I'm used to being able to do wit
>>package Apache::Foo;
>>$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
>>sub handler { };
>>
>>now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
>>there are a few modules on CPAN that do this, IIRC.
>
>
> Yes, but this has always been partially broken as it is.
>
Philippe M. Chiasson wrote:
[...]
You mean it will break their code. In which case I'd suggest not to commit
this patch till you get it all ready.
Yeah, well, things are already broken quite a bit w/r to
sections, so I wanted to fix a problem at a time, even though if it
temporarely introduces
Geoffrey Young wrote:
well, as I said, add_config() can't accomplish the same thing. in fact,
every time I've tried to use add_config() the way I want I haven't
been able
to. not that it's not useful for some things, but it's not useful for
the
level of trickery that I'm used to being able to do
On Wed, 2003-12-10 at 12:53, Geoffrey Young wrote:
> >>package Apache::Foo;
> >>$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> >>sub handler { };
> >>
> >>now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> >>there are a few modules on CPAN that do this, IIRC.
> >
>> add_config() is equivalent to an .htaccess file - whatever overrides
>> govern
>> .htaccess files' ability to have directives inserted into the
>> configuration
>> will apply to add_config() as well. that is very different from
>> ReadConfig's blind addition of directives into the config.
>
>
On Wed, 2003-12-10 at 14:14, Geoffrey Young wrote:
> >> add_config() is equivalent to an .htaccess file - whatever overrides
> >> govern
> >> .htaccess files' ability to have directives inserted into the
> >> configuration
> >> will apply to add_config() as well. that is very different from
> >> R
Philippe M. Chiasson wrote:
so maybe at startup it's not a bad idea after all :)
So, does this mean that you don't have a specific objection against
deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
future in favor of ->add_config("User foo") ?
The problem with add_config()
28 matches
Mail list logo
