http://www.perlmonks.org?node_id=654149


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

Sadly, it does not seem very informative. Telling me that the value has been stored (which I know) and that the cache has been hit (which I know).

Other than that, it is very silent

-=( Graq )=-

Replies are listed 'Best First'.
Re^3: Memcache 'get' returns undef running under mod_perl (debug)
by tye (Sage) on Nov 30, 2007 at 17:16 UTC

    To continue with the simple and obvious suggestions (that you may have already tried), add "-vv" to your memcached command line. (I was also suspicious of your "-u root" as hsinclai highlighted but it'd also be interesting to learn of the mechanics of the failure.)

    - tye        

      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 )=-

        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        

        Sir, I don't know where is the FilterHandler file is. Could please tell me?