Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^4: Memcache 'get' returns undef running under mod_perl (debug)

by graq (Curate)
on Dec 03, 2007 at 10:05 UTC ( #654534=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Memcache 'get' returns undef running under mod_perl (debug)
in thread Memcache 'get' returns undef running under mod_perl

The problem lay in the FilterHandler's invocation of other classes.

The code looked a little like this

$html =~ s/<\?KEYWORD\s+([^\?^>]+)\??>/$self->handle($1)/gme;

Changing this to

$html =~ s/<\?KEYWORD\s+([^\?^>]+)\??>/$self->handle($1)/ge; # Removed multiline option 'm'

fixed the memcache problem.

It seems to alter memcache's behaviour in GetParser when checking $self->[BUF]

if ($self->[BUF] =~ /^END\r\n/) { $self->[ON_ITEM] = undef; return 1; # we're done successfully, return 1 to finish }

Looks like m fighting with S*

-=( Graq )=-


Comment on Re^4: Memcache 'get' returns undef running under mod_perl (debug)
Select or Download Code
Replies are listed 'Best First'.
Re^5: Memcache 'get' returns undef running under mod_perl (debug)
by tye (Cardinal) on Dec 03, 2007 at 17:33 UTC

    To be honest, that makes no sense. /m only impacts the meaning of ^ and the only '^'s in the regex you show are inside a character class and so aren't impacted by /m.

    If this change fixed the mod_perl client, then it does remind me of mod_perl bugs I've seen before. Usually these bugs are heisenbugs, however, coming and going depending on how long a given Apache process has been running, though I guess I have seen some persistent ones (and rarely ones that persisted until the master Apache process was restarted).

    In any case, bug(s) I've seen cause rather weird regex behavior. For example, /\d\d/g will sometimes fail on a string full of pairs of digits (and you'll see a node temporarily tagged as being written "never"). Or I've had several complex regexes that mod_perl refused to parse even though they were correct and worked outside of mod_perl. Changing to a different delimiter was the most common solution.

    Although I don't understand your explanation of the workings of this bug, it certainly looks like a Perl bug if dropping /m does what you describe (note that Perl bugs are more likely to be visible in mod_perl because the Perl interpretter runs for so long). It sounds like perhaps the /m on the one regex is, in mod_perl, making the /^END\r\n/ behave as if it had a /m on it.

    - tye        

      Interesting. Testing it a little further, it appears that it is the combination /me causing the problems. Removing just the 'm' to give

      $html =~ s/<\?KEYWORD\s+([^\?^>]+)\??>/$self->handle($1)/ge;

      does make it 'work'.

      However, I need the match to be multiline. Re-introducing the /m option in a loop also makes things work:

      my $MAX = 100; while( $html =~ m/<\?KEYWORD\s+([^\?^>]+)\??>/m ) { my $ssi_html = $self->handle($1); $html =~ s/<\?KEYWORD\s+([^\?^>]+)\??>/$ssi_html/m; last if $MAX++ > 100; }

      -=( Graq )=-

Re^5: Memcache 'get' returns undef running under mod_perl (debug)
by Anonymous Monk on Jul 27, 2013 at 02:41 UTC
    Sir, I don't know where is the FilterHandler file is. Could please tell me?

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (13)
As of 2015-07-31 21:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (282 votes), past polls