Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

weired problem with mod_perl

by opensourcer (Monk)
on Apr 18, 2007 at 02:55 UTC ( #610687=perlquestion: print w/ replies, xml ) Need Help??
opensourcer has asked for the wisdom of the Perl Monks concerning the following question:

hi, i have written a web app. in mod_perl, The app. takes a job/task from user and submits to server. when the job/task gets submitted to the server, the job/task status should be "zero"(0=new*) until its start executing the job/task. It show "zero", when the job/task gets executed while pressing the refresh(continuous/leaving a gap) to know the status, some times the status of the job/task show "zero" or "one"(one=stated*). When i restart the apache/mod_perl, i get the perfect status. i don't c the changing of icons. * i have replaced the text with icons based on numbers like 0=some icon, 1= some ...........
- opensourcer.

Comment on weired problem with mod_perl
Re: weired problem with mod_perl
by TOD (Friar) on Apr 18, 2007 at 04:46 UTC
    your problem must not necessarily be one of mod_perl, because some browsers (firefox i.e.) send several main requests for the same content to the server, in order to get the contents as quick as possible and to start rendering as soon as possible.
    one solution might lie in mod_evasive, but unfortunately it will treat any requests for media on the page as main requests and block most of them. i once tried my own luck with a connection handler, but failed: Apache2 Perl(Pre|Process) ConnectionHandler. if you really need a distinct and unique status flag you probably better rely on session objects.
Re: weired problem with mod_perl
by varian (Chaplain) on Apr 18, 2007 at 06:40 UTC
    One of the caveats of ModPerl is that global variables retain their value because your program never really exits (unless you restart the Apache server).

    And given that Apache is a multithreaded server the next client HTTP request may be serviced by the same or by a different Apache child process. So if one accidentally uses the retained value of the global variable it may well hold the status for a vastly different request, you never know.

    From the symptoms that you have described it appears to be related to the above caveat. A similar case was discussed in this ModPerl thread.

    Clearly the recommendation is to avoid globals and when you have to use them double check you instantiate them in your handler, there's no "not initialized" warnings that you can rely on to help you debug.

      In responce to ur suggestion(about the global variables), what i did, i changed something in my database and my web page did'nt update me with that update, it did updated only when i restart the apache.
      opensourcer
Re: weired problem with mod_perl
by andye (Curate) on Apr 18, 2007 at 08:11 UTC
    varian has some good points on the way mod_perl works. That could be your problem.

    This could also be a caching issue, and nothing to do with mod_perl: what happens is that the browser, or a proxy server at the ISP, caches the web page that you produce.

    So, when the user requests the same page again, it's served out of the cache, rather than being requested again from your server.

    Obviously this is great for static content, but a bit of a problem for content that changes each time it's requested. It can't always be solved by getting the user to change their browser settings (even if that were practical for a public site, which it usually isn't) because the problem can also be caused by reverse caching proxy servers between your server and the user. AOL used to be particularly bad for this, I don't know if they still are.

    Anyway, the solution I've always used, which has the virtue of simplicity, is to append the time to the end of the URL when you request it. Obviously you need to arrange things so that the link to the dynamic page is itself dynamically generated. So you just need to make your HTML something like this:

    '<A HREF="http://www.example.com/script.pl?r='.time().'">'

    The reason that works is that the caching proxy server - or the browser - sees it as a request for a different URI to the previous one, so doesn't return the cached copy.

    You can also play around with HTTP headers and so on to (in theory) prevent caching - my experience has been that this will work OK for the browser, but not necessarily for caching proxy servers.

    HTH!

    Best wishes, andye

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://610687]
Approved by neversaint
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2014-07-25 05:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (167 votes), past polls