You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by "Steven D. Arnold" <st...@permanent.cc> on 2000/04/19 21:48:13 UTC
problem solved, but still weird!
Hey folks,
Well, my script seems to be running correctly now, but I don't understand why.
I added 8192 to the debug value so I could get the in-browser links to the
debugging information. I also created an EMBPERL_VIRTLOG entry. I then
stopped and started apache, and for some reason it now works!
I am very pleased/impressed with the in-browser debugging
information. This ought to be very handy as I continue EmbPerl
development. Thanks to the author for a cool program.
steve
Re: problem solved, but still weird!
Posted by barries <ba...@slaysys.com>.
On Sat, Apr 07, 2001 at 07:15:50PM -0700, Marcus R. Popetz wrote:
> At 01:29 PM 4/7/01, Steven D. Arnold wrote:
> >Hey folks,
> >
> >Well, my script seems to be running correctly now, but I don't understand why.
> >
> >I added 8192 to the debug value so I could get the in-browser links to the
> >debugging information. I also created an EMBPERL_VIRTLOG entry. I then
> >stopped and started apache, and for some reason it now works!
>
> Had you defined foo and used it once without the method new() declared? If
> so, as I mentioned in an earlier email, mod_perl will only reload files who
> mod date has change if they are in @INC. Since you aren't running with
> 'use strict;' it probably wouldn't complain about calling an undefined
> method...
mod_perl won't reload modules by itself, you need Apache::Reload or
equivalent. Setting PerlFreshRestart allows it to happin if you do a
restart or graceful restart, but some modules don't take kindly to that
treatment, so Apache::Reload is a better way in most situations.
- Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: problem solved, but still weird!
Posted by "Marcus R. Popetz" <mp...@netility.com>.
At 01:29 PM 4/7/01, Steven D. Arnold wrote:
>Hey folks,
>
>Well, my script seems to be running correctly now, but I don't understand why.
>
>I added 8192 to the debug value so I could get the in-browser links to the
>debugging information. I also created an EMBPERL_VIRTLOG entry. I then
>stopped and started apache, and for some reason it now works!
Had you defined foo and used it once without the method new() declared? If
so, as I mentioned in an earlier email, mod_perl will only reload files who
mod date has change if they are in @INC. Since you aren't running with
'use strict;' it probably wouldn't complain about calling an undefined
method...
-mp
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: problem solved, but still weird!
Posted by Wim Kerkhoff <wi...@netmaster.com>.
On 20-Apr-2000 Ulrike Schepp wrote:
> Hi Steven!
>
> The same problem ocurred here and i spent a little time in looking for the
> circumstances when this occurs.
>
> On Wed, 19 Apr 2000, Steven D. Arnold wrote:
>
> [...]
>
>> I added 8192 to the debug value so I could get the in-browser links to
>> the debugging information. I also created an EMBPERL_VIRTLOG entry.
>> I then stopped and started apache, and for some reason it now works!
>
> The crucial point was the restart of your apache. I found, that the
> external modules which are linked into the script via the "use ..."
> statement are somehow cached within the memory of the apache. It's the
> same problem if i call the "use..." within [-...-] tags or in the [!... !]
> tags.
If this is the case, I've added Apache::StatINC to httpd.conf:
<FilesMatch *.htm*>
SetHandler perl-script
Options ExecCGI
PerlHandler HTML::Embperl
PerlInitHandler Apache::StatINC
PerlSendHeader On
order allow,deny
allow from all
</FilesMatch>
Soo if you chane your foo.pm, mod_perl will detect that and recompile foo.pm.
I removed the loading my custom modules "foo.pm" in my startup.pl as well,
until I'm done developing and modifying it. I don't know if I really needed to
do this, though?
The mod_perl guide (perl.apache.org/guide) has more info on this.
Regards,
Wim Kerkhoff, Software Engineer
NetMaster Networking Solutions
wim@netmaster.com
Re: use module in Embperl (was: problem solved, but still weird!)
Posted by Frerk Meyer <fm...@channel-one.de>.
Thanks Gerald for the clearing up things. Additionally:
I've found an excellent tutorial on Modules under mod_perl
(and therefore with embperl as well) which explains many
of the issues which have bugged me and many others:
http://www.perlmonth.com/columns/perl_apache/perl_apache.html?issue=11
--
Frerk Meyer mailto:fm@channel-one.de
Channel.One http://www.channel-one.de
RE: use module in Embperl (was: problem solved, but still weird!)
Posted by Gerald Richter <ri...@ecos.de>.
>
> Standard workaround here is now "apachectl restart" after the change of
> modules :-/ weird but it really works!
>
Nothing weird here. Everything is well defined. Just let us try to
understand how Perl, mod_perl and Embperl works together:
"perldoc -f use" tells us:
Imports some semantics into the current package from the named module,
generally by aliasing certain subroutine or variable names into your
package. It is exactly equivalent to
BEGIN { require Module; import Module LIST; }
except that Module must be a bareword.
So what's important here for us is, that use executes a require and this is
always done before any other code is executed.
"perldoc -f require" says (among other things):
..., demands that a library file be included if it hasn't already
been included.
and
Note that the file will not be included twice under the same specified
name.
So now we know (or should know) that mod_perl starts the Perl interpreter
once when Apache is started and the Perl interpreter is only terminated when
Apache is terminated. Out of these two things follows, that a module that is
loaded via use or require is only loaded once and will never be reloaded,
regardless if the source changes or not.
So far this is just standard Perl. Things get's a little bit more difficult
when running under mod_perl (only Unix), because Apache forks a set of child
processes as neccessary and from the moment they are forked, they run on
their own and don't know of each other. So if a module is loaded at server
startup time (before the fork), it is loaded in all childs (this can be used
to save memory, because the code will actually only reside once in memory),
but when the modul is loaded inside the child and the source changes, it
could be happen, that one child has loaded an ealier version and another
child has loaded a later version of that module, depending on the time the
module is actualy loaded by the child.
That explains, why sometimes it works and sometimes it doesn't, simply
because different childs has loaded different versions of the same module
and when you reload your page you hit different childs of Apache!
Now there is one point that is special to Embperl to add. Since Embperl
compiles every page in a different namespace, a module that doesn't contains
a "package foo" statement is compiled in the namespace of the page where it
is first loaded. Because Perl will not load the module a second time, every
other page will not see subs and vars that are defined in the loaded module.
This could be simply avoided by giving every module that should be loaded
via use/require an explicit namespace via the package statement.
So what can we do?
- If a module change, simply restart Apache. That's works always.
- use Apache::StatInc. This will do a stat on every loaded module and
compare the modification time. If the source has changed the module is
reloaded. This works most times (but not all modules can be cleanly
reloaded) and as the number of loaded modules increase, your sever will slow
down, because of the stat it has to do for every module.
- Use "do" instead of "require". do will execute your file everytime it is
used. This also adds overhead, but this may be accpetable for small files or
in a debugging environement. (NOTE: Be sure to check $@ after a do, because
do works like eval)
I hope now it's seem a little bit less weird..
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: problem solved, but still weird!
Posted by Ulrike Schepp <u....@gigabell.net>.
Hi Steven!
The same problem ocurred here and i spent a little time in looking for the
circumstances when this occurs.
On Wed, 19 Apr 2000, Steven D. Arnold wrote:
[...]
> I added 8192 to the debug value so I could get the in-browser links to
> the debugging information. I also created an EMBPERL_VIRTLOG entry.
> I then stopped and started apache, and for some reason it now works!
The crucial point was the restart of your apache. I found, that the
external modules which are linked into the script via the "use ..."
statement are somehow cached within the memory of the apache. It's the
same problem if i call the "use..." within [-...-] tags or in the [!... !]
tags.
Also i suspect some esotheric "lifetime" for the cached modules,
because if i retry on a changed module which was already "cached", the try
some hours later is more likely successfull than the call immediately
after the change...
I think, that is more a problem of the mod_perl module of the apache but i
hadn't the time, to proof it. Perhaps, there is someone out there, who has
more experience with the mod_perl internals.
Standard workaround here is now "apachectl restart" after the change of
modules :-/ weird but it really works!
Regards
Ulrike
--
* NAMES: Ulrike Schepp Gigabell AG
* PHONE: [+49] [0]69 - 17084-742 D-60325 Frankfurt
* ENCR.: Key 0x5E34C939 B0 B1 ED D0 51 D1 0C 3B 82 23 2C 61 10 38 57 95
* SIGN : Key 0x59AFB1C5 59 5D 53 37 2F 79 A0 2F 27 03 F7 23 58 EE B9 6C