Re: Embperl logging "out of control"

[Ed Grimm <ed...@dsblade00.wat.us.ray.com>]

Assuming you haven't found a resolution to the issue yet...

Have you tried running running Apache with a single child (MaxClients
1) to try to help isolate the issue?  I realize this is only a viable
setup on a test machine.

The code hack in me would probably try putting something along the lines
of the following on a page, and then seeing if it affected the logging
of that page:

[- $ENV{EMBPERL_DEBUG} = -1; $ENV{EMBPERL_OPTIONS} = 1024|131072; -]
[- $ENV{EMBPERL_DEBUG} = 0; $ENV{EMBPERL_OPTIONS} = 1024; -]

The purpose behind this twiddling is that in some environments (I don't
believe that EmbPerl is one of them, but I don't know for certain) there
are multiple variables which track the same settings; the public
interface has nothing to do with the actual functioning, other than
being used to detect changes to the settings.  In these environments, if
the different variables somehow get out of sync, setting the public
interface varaible to the value it already has may not trigger a change
to be replicated to the internal state.

Ed

On Thu, 13 Dec 2007 Tim_Grant@vwr.com wrote:

>>We had an incident like that back in our development of our pages.  We
>>tracked it down to someone having set EMBPERL_DEBUG to -1 in one of
>>their pages, and assumed that the automatic garbage collection at the
>>end of the page would fix it up.  So whenever an apache child showed
>>that page, it'd start logging like this.
>
> Great tip. Doesn't seem to be what's happeninig here.
>
>>I found it by grepping the log file for EMBPERL_DEBUG, if I remember
>>correctly.  Note that it didn't actually log the section that did it to
>>us on the *first* pass through that page for any child.  But it did, of
>>course, tattle if a child showed the same page twice.
>
> Grepping our logs for EMBPERL_DEBUG returned no results.
>
>>Of course, if the bug was in perl code, rather than one of our pages, we
>>wouldn't have caught it that way.  Instead, we'd have caught it from my
>>earlier grep of all of our perl code and all of the non-EmbPerl library
>>code for EMBPERL_DEBUG.
>
> Grepping our code for EMBPERL_DEBUG returned no results.
>
>>Note that, while it wouldn't solve your issue, you could make a web page
>>to report those same variables, and when you found out which one was
>>wrong, modify some pages to fix it.
>
> We have a report page. Here's an excerpt:
>
> EMBPERL_COMPARTMENT test
> EMBPERL_DEBUG 0
> EMBPERL_LOG /www/logs/www.vwrsp.com.embperl.log
> EMBPERL_OPTIONS 1024
> EMBPERL_SESSION_HANDLER_CLASS no
>
> ...
>
> REDIRECT_EMBPERL_COMPARTMENT test
> REDIRECT_EMBPERL_DEBUG 0
> REDIRECT_EMBPERL_LOG /www/logs/www.vwrsp.com.embperl.log
> REDIRECT_EMBPERL_OPTIONS 1024
> REDIRECT_EMBPERL_SESSION_HANDLER_CLASS no
>
> When I look at that, it says to me that Embperl logging should be off. I've
> reloaded the page a lot, and haven't seen the EMBPERL_DEBUG variable
> change.
>
> (BTW, I don't know what this redirect stuff is. I've seen very little
> mention of it on the internet.)
>
>>>I am assuming that all of your processing is within Apache.
>
> Correct.
>
> --
> Regards,
> Tim Grant
> Application Developer, VWR International
> 610-719-7097
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org