Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

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

by graq (Curate)
on Nov 30, 2007 at 16:59 UTC ( #654149=note: print w/ replies, xml ) Need Help??


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


Comment on Re^2: Memcache 'get' returns undef running under mod_perl (debug)
Replies are listed 'Best First'.
Re^3: Memcache 'get' returns undef running under mod_perl (debug)
by tye (Cardinal) 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?

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (13)
As of 2015-07-31 13:41 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 (277 votes), past polls