Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
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
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 scrutinizing the Monastery: (16)
As of 2014-08-01 14:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (25 votes), past polls