> I just got hold of VC++ 6.0 and was waiting for 2.0.49 to be release before
> trying to compile everything again. but now that it's out I'll give it all
> another whirl with the more recent version and see how it goes.
>
> one of the things on my hit list is post-connect being called 4x instea
Geoffrey Young wrote:
one of the things on my hit list is post-connect being called 4x
instead of
2x like on unix, since that seems to be a major difference between the
platforms. but no sense guessing...
Earlier Bill posted a trick how to avoid this situation (i.e.
controlling how many times a
>> one of the things on my hit list is post-connect being called 4x
>> instead of
>> 2x like on unix, since that seems to be a major difference between the
>> platforms. but no sense guessing...
>
>
> Earlier Bill posted a trick how to avoid this situation (i.e.
> controlling how many times a
Geoffrey Young wrote:
Well, now that 2.0.49 is out I was finally able to try the latest Apache
stuff with your hook ordering patch (I still don't know to build CVS
Apache 2 on Win32), but unfortunately it still doesn't work. The usual
invalid handle error, same as before.
thanks for trying :)
> Well, now that 2.0.49 is out I was finally able to try the latest Apache
> stuff with your hook ordering patch (I still don't know to build CVS
> Apache 2 on Win32), but unfortunately it still doesn't work. The usual
> invalid handle error, same as before.
thanks for trying :)
I just got h
Steve Hay wrote:
> Geoffrey Young wrote:
>
>> so cool, we've isolated the "I can't start problem" to something in
>> apr_hook_sort_all().
>>
>> so I guess the place to start looking is apr_hooks.c. I'll take a
>> look at
>> it some more and throw in some debugging statement to see if anything
>
Geoffrey Young wrote:
>>>the only thing I could suggest at this point is to comment out the
>>>apr_hook_sort_all() call in modperl_apache_resort_hooks() to see if there
>>>isn't something about that function (or calling it) that is mucking up the
>>>works. what that would leave is the altering of
>>ok. I don't suppose that sleeping between startups makes a difference?
>>
>
> Sleeping between what? One test /on its own/ doesn't work!
yes, I realized after I sent it that you already found the problem has
nothing to do with stopping or starting. oops :)
>>the only thing I could suggest
Geoffrey Young wrote:
>Geoffrey Young wrote:
>
>
>>stas at one point
>>suggested nulling the table when I'm done with it, which might also be an
>>idea
>>
>>
>
>to that end, here is yet another patch to try.
>
Nope :( Still the same results for me I'm afraid.
- Steve
---
Geoffrey Young wrote:
>>The ReallyFirst test runs OK on its own, though.
>>
>>
>
>it seems I forgot to add a -DReallyFirst, so this is running the default as
>well.
>
Doh! Have you added it now? I've built & installed this new patch and
I still find that -DReallyFirst works fine...
>
>
>
>>I'm still unclear as to whether this is a fault of the new hook-ordering
>>implementation, or a symptom of the way I chose to setup the tests. does it
>>behave the same way against pristine mod_perl CVS?
>>
>
> How can I try that?! If I run it against pristine mp2 CVS then it
> complains "In
Geoffrey Young wrote:
>>I've now got the same problem as you, Randy -- it runs one set of tests
>>OK (all successful), but then hangs trying to start the server the
>>second time.
>>
>>
>
>consistency is good :)
>
>I'm still unclear as to whether this is a fault of the new hook-ordering
>imp
> I've now got the same problem as you, Randy -- it runs one set of tests
> OK (all successful), but then hangs trying to start the server the
> second time.
consistency is good :)
I'm still unclear as to whether this is a fault of the new hook-ordering
implementation, or a symptom of the way
Geoffrey Young wrote:
but you need to pass pool... so may be not... just another idea to make
mod_perl.c less cluttered.
passing the pool isn't that big a deal, or I could just use
modperl_global_get_pconf(), in which case I'll also need to use pconf for
the logic in modperl_cmd then (instead of
> Actually, you don't even need modperl_apache_init_hook_order(), just
> move that init code into: modperl_apache_get_hook_order();
>
> void modperl_apache_get_hook_order(apr_pool_t *p) {
> if (!hook_order) {
> hook_order = apr_table_make(p, 0);
> }
> return hook_order;
> }
I
Geoffrey Young wrote:
It should be:
modperl_apache_init_hooks(p);
void modperl_apache_init_hook_order(apr_pool_t p) {
hook_order = apr_table_make(p, 0);
}
ok, I'll do that. I was trying to solve a very strange problem that I
couldn't figure out (but would probably obvious to someone e
> It should be:
>
> modperl_apache_init_hooks(p);
>
> void modperl_apache_init_hook_order(apr_pool_t p) {
> hook_order = apr_table_make(p, 0);
> }
ok, I'll do that. I was trying to solve a very strange problem that I
couldn't figure out (but would probably obvious to someone else, na
Randy Kobes wrote:
>On Mon, 1 Mar 2004, Steve Hay wrote:
>
>
>>What do I do with the hook_order_test-mp2.tar.gz tests? Pardon my
>>ignorance, but I have no idea where to put these files or what to do
>>with them.
>>
>>
>
>If I recall, you have the Win32 apxs installed? If so, all
>you need
Randy Kobes wrote:
ThreadsPerChild 50
MaxRequestsPerChild 0
The standard mp2 testsuite now passes all tests successful.
I forgot to mention - I've also found lately that raising
this limit is necessary.
Any idea why? 50 threads is not enough to run the tests, when with prefork
onl
Geoffrey Young wrote:
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.210
diff -u -r1.210 mod_perl.c
--- src/modules/perl/mod_perl.c 1 Mar 2004 04:24:00 -
On Mon, 1 Mar 2004, Steve Hay wrote:
> Geoffrey Young wrote:
[ ... ]
> >ok, I'll hold off on committing then. attached is the final patch I would
> >have put in this evening, fwiw.
> >
> >as I mentioned, I'd be interested to know if the test suite I had sent runs
> >against current pristine CVS -
Geoffrey Young wrote:
>>>or you could just comment out each
>>>different startup in TEST.PL (or just TEST if you don't feel like running
>>>Makefile.PL each time) and run each one at a time.
>>>
>>>
>>I just did that - only two of the tests sequences run
>>individually - one where -defines i
>> or you could just comment out each
>>different startup in TEST.PL (or just TEST if you don't feel like running
>>Makefile.PL each time) and run each one at a time.
>
>
> I just did that - only two of the tests sequences run
> individually - one where -defines is '' and the other when
> it's 'R
On Sun, 29 Feb 2004, Geoffrey Young wrote:
>
> > Hi Geoff,
>
> hey randy. hope you had a nice vacation :)
Thanks :) Actually, it was a bunch of meetings for deciding
on some grants, which was interesting, but stressful ...
> >However, when running the tests, what happens is that the
> > tes
> Hi Geoff,
hey randy. hope you had a nice vacation :)
> I've tried this out on Win32 - nice work! Just a small
> thing - in src/modules/perl/modperl_apache.c, there's a
> declaration of 'int j' in modperl_apache_resort_hooks() that
> VC++ didn't like occurring so late - moving it up near t
On Sun, 29 Feb 2004, Geoffrey Young wrote:
> here's another pass that incorporates the suggestions thus
> far. comments on the global foo appreciated. the tests I
> posted before are still valid at this point.
>
> --Geoff
Hi Geoff,
I've tried this out on Win32 - nice work! Just a small
thin
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
Much better, but still why having any data at all in mod_perl.c? Have
the static variable in modperl_apache.c and provide an accessor to do:
hook_order = apr_table_make(p, 0);
from modperl_apache.c. Now you are all set.
well, I ca
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>> Much better, but still why having any data at all in mod_perl.c? Have
>>> the static variable in modperl_apache.c and provide an accessor to do:
>>>
>>> hook_order = apr_table_make(p, 0);
>>>
>>> from modperl_apache.c. Now you are all set.
>>
>>
>
Geoffrey Young wrote:
Much better, but still why having any data at all in mod_perl.c? Have
the static variable in modperl_apache.c and provide an accessor to do:
hook_order = apr_table_make(p, 0);
from modperl_apache.c. Now you are all set.
well, I can't see where to draw the pool from or how e
> Much better, but still why having any data at all in mod_perl.c? Have
> the static variable in modperl_apache.c and provide an accessor to do:
>
> hook_order = apr_table_make(p, 0);
>
> from modperl_apache.c. Now you are all set.
well, I can't see where to draw the pool from or how else to in
Geoffrey Young wrote:
here's another pass that incorporates the suggestions thus far. comments on
the global foo appreciated. the tests I posted before are still valid at
this point.
Much better, but still why having any data at all in mod_perl.c? Have the
static variable in modperl_apache.c and
here's another pass that incorporates the suggestions thus far. comments on
the global foo appreciated. the tests I posted before are still valid at
this point.
--Geoff
Index: lib/ModPerl/Code.pm
===
RCS file: /home/cvspublic/modper
> This is exactly what I was talking about. Making it configurable at
> startup time.
:)
actually, once I got it figured out, it's probably possible to support
per-dir hook ordering as well, but I don't think it's valuable enough to
warrant additonal effort. but it's possible ;)
> I don't know
On Fri, 2004-02-27 at 09:17, Geoffrey Young wrote:
> hi all
>
> ok, I spent some time and was able to get configuration-based dynamic hook
> ordering working.
Great!
> the attached patch adds a PerlHook*Handler directive for each request phase
> (minus the PerlResponseHandler). so, you would ha
>> the whole idea of static C variables/structs and threaded mpms really,
>> really confuses me. but I guess it doesn't matter, since it's not a
>> per-request thing and all this happens before ap_mpm_run is called
>> anyway.
>
>
> You don't have any threads till the child_init phase, so there
Geoffrey Young wrote:
+/* we need to hook a few internal things before APR_HOOK_REALLY_FIRST */
+#define MODPERL_HOOK_REALLY_FIRST (-20)
The name is confusing, since APR_REALLY_FIRST is -10 and you kept the
rest of the MODPERL_HOOK_ names matching . Call it REALLY_REALLY_FIRST?
or anything else w
>> +/* we need to hook a few internal things before APR_HOOK_REALLY_FIRST */
>> +#define MODPERL_HOOK_REALLY_FIRST (-20)
>
>
> The name is confusing, since APR_REALLY_FIRST is -10 and you kept the
> rest of the MODPERL_HOOK_ names matching . Call it REALLY_REALLY_FIRST?
> or anything else which
Geoffrey Young wrote:
hi all
ok, I spent some time and was able to get configuration-based dynamic hook
ordering working.
the attached patch adds a PerlHook*Handler directive for each request phase
(minus the PerlResponseHandler). so, you would have a configuration like this
PerlHookTransHandle
hi all
ok, I spent some time and was able to get configuration-based dynamic hook
ordering working.
the attached patch adds a PerlHook*Handler directive for each request phase
(minus the PerlResponseHandler). so, you would have a configuration like this
PerlHookTransHandler Last
valid values
Geoffrey Young wrote:
what bothers me about -D is that, the more I think about it, we're
using -D
in a way neither intended by core nor used by other modules. -D is
specifically for containers, while using -D in this way has
little do to with that.
Not really, -D is used for many other things i
>> what bothers me about -D is that, the more I think about it, we're
>> using -D
>> in a way neither intended by core nor used by other modules. -D is
>> specifically for containers, while using -D in this way has
>> little do to with that.
>
>
> Not really, -D is used for many other things in
well, the problem with changing the source is that modperl_hooks.c is
autogenerated - they'd need to know to alter ModPerl::Code, which is kinda
less intuitive unless you're one of us :)
right, I haven't thought of that, but only looked at modperl_register_hooks in
mod_perl.c
what bothers me abo
>> anyway, I'm not entirely convinced that -D switches are the way to go
>> with
>> this (imagine the jumble trying to shift just a few phases), but it's
>> something to chew on over the weekend :)
>
>
> I'd think that the majority of the users won't need that feature.
I agree
> Those
> few wh
I wonder whether one really has to call the hooks registration from
modperl_register_hooks. May be it's possible to postpone the ap_hooks calls
until after the startup phase is over (let's say postconfig). In which case we
could provide extended config directives to do the configuration.
__
Geoffrey Young wrote:
httpd -DTRANS_REALLY_LAST -DRESPONSE_REALLY_FIRST
[...]
anyway, I'm not entirely convinced that -D switches are the way to go with
this (imagine the jumble trying to shift just a few phases), but it's
something to chew on over the weekend :)
I'd think that the majority of the
Geoffrey Young wrote:
I don't think it's impossible, but I think it will be hard - we'd
basically
need to change the nOrder value in the each hook structure at some point
then call apr_hook_sort_* manually. I might be able to do this when some
directive is parsed or it may need to be a request-tim
>>httpd -DTRANS_REALLY_LAST -DRESPONSE_REALLY_FIRST
>>
>>etc...
>>
>>so it would be neither a compile time option, nor a configuration
>>option, but a program define.
well this was the harder of the two (compile time vs configure time) to
implement, so I started with it :)
attached is a rough pa
>> I don't think it's impossible, but I think it will be hard - we'd
>> basically
>> need to change the nOrder value in the each hook structure at some point
>> then call apr_hook_sort_* manually. I might be able to do this when some
>> directive is parsed or it may need to be a request-time oper
> Maybe I'm missing something, but it doesn't seem like such a problem. If I
> make my own module DSO in C and I add the hook when the module loads
> (LoadModule) for TransHandler, and I'm using compiled-in mod_proxy, I'll
> have the same issue. Frankly, even if they're both compiled in, I
> po
Geoffrey Young wrote:
[...]
Making it a startup configuration should be possible, IMO. Only if that
turns out to be impossible, I'd make it a compile-time option.
I don't think it's impossible, but I think it will be hard - we'd basically
need to change the nOrder value in the each hook structure
- Original Message -
From: "Stas Bekman" <[EMAIL PROTECTED]>
To: "Geoffrey Young" <[EMAIL PROTECTED]>
> Geoffrey Young wrote:
> > I've brought it up before, but it looks like users are having real
problems
> > with the way 2.0 hooks modules into the request phases.
> >
> > in 1.0, modul
> I don't know about a compile-time option personally. I can just see it
> causing lots more problems than solving anything. It would introduce a
> huge number of basically different mod_perls, with different behaviour
> for the same user code, making bug tracking et all even more
> problematic.
> Sounds fine to me.
k
>
> What happens if another module has also used REALLY_FIRST? You still
> can't ensure 100% that mp's handler will run first.
well, I'm going to play around with some constants and see how it all falls
out. REALLY_FIRST is just -10, so maybe MOD_PERL_REALLY_FIRST could
On Thu, 2004-02-19 at 19:56 -0500, Geoffrey Young wrote:
> [...]
> so, I'd like to suggest that at least for the request-time hooks we move
> mod_perl to APR_HOOK_REALLY_FIRST. this will give users similar behavior to
> the way mod_perl used to work in 1.0.
It does make sense to me and would actu
Geoffrey Young wrote:
I've brought it up before, but it looks like users are having real problems
with the way 2.0 hooks modules into the request phases.
in 1.0, module order was determined by compile-time ordering or
LoadModule/ClearModuleList/AddModule, neither of which exist in 2.0, where
Apache
I've brought it up before, but it looks like users are having real problems
with the way 2.0 hooks modules into the request phases.
in 1.0, module order was determined by compile-time ordering or
LoadModule/ClearModuleList/AddModule, neither of which exist in 2.0, where
Apache chose the HOOK_FIRST
56 matches
Mail list logo
