Hi. This is a rather comprehensive (read 'cathartic') message, so if you
have something productive to go and do, then you'd probably be better
off doing that. For all other interested parties, read on....

I've done a few more tests and isolated this to my production server
only. pnotes() works fine on my workstation. And the problems described
below apply to notes() too. So it's something to do with my
apache/mod_perl installation. Take a look at this:

I've cut down the production server to a bare bones httpd.conf with the
following virtual hosts section:
<VirtualHost *>
        DocumentRoot /home/mark/lib
        ServerName localhost
        <Location />
                PerlFixupHandler Handler1
                PerlHandler Handler2
                PerlLogHandler Handler3
        </Location>
</Virtualhost>

my startup.pl looks like this:
#!/usr/bin/perl
require '/home/mark/lib/Test.pl';
1;

And Test.pl looks like this:
package Handler1;
sub handler {
        my $r = shift @_;
        $r->pnotes('note1', 'msg1');
        warn "HANDLER1 says: " . $r->pnotes('note1');
        return OK;
}
package Handler2;
sub handler {
        my $r = shift @_;
        $r->pnotes('note2', 'msg2');
        warn "HANDLER2 says: " . $r->pnotes('note2');
        warn "HANDLER2 got: " . $r->pnotes('note1');
        $r->send_http_header('text/html');
        $r->print("Hello World!\n");
        return OK;
}
package Handler3;
sub handler {
        my $r = shift @_;
        warn "HANDLER3 got: " . $r->pnotes('note1') .
        ' and ' . $r->pnotes('note2');
        return OK;
}
1;

This gives an output in error_log of the following:
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER2 says: msg2 at /home/mark/lib/Test.pl line 12.
HANDLER2 got: msg1 at /home/mark/lib/Test.pl line 13.
HANDLER3 got: msg1 and  at /home/mark/lib/Test.pl line 21.

Which shows that pnotes can pass data from the Fixup handler to the
Response handler, but anything the Response handler sets is lost by the
time the Logging handler is called. Although the data that the Fixup
handler sets is still there. 

Question: Why is the Fixup handler being called 3 times? If you look at
the sniffer output I've included, you'll see there's a single request
and response. I checked the URI that was being called and it's '/' in
all three cases.

Just to be sure, I added this to Handler2 (the Response handler)
if($r->is_main())
{
   $r->print('You are in main');
}
And it prints out the string. So it is the main request. 

Here is some more info:
When I did this test, I stripped out everything from httpd.conf (relying
heavily on vim's undo feature because this server will be live in 48
hours, pnotes or no pnotes!).

Here is the output from httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_rewrite.c
  mod_access.c
  mod_auth.c
  mod_proxy.c
  mod_headers.c
  mod_setenvif.c
  mod_gzip.c
  mod_perl.c
suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec

Here is the output from httpd -V:
Server version: ZipTree (Unix)
Server built:   Jul  8 2003 12:56:03
Server's Module Magic Number: 19990320:13
Server compiled with....
 -D HAVE_MMAP
 -D HAVE_SHMGET
 -D USE_SHMGET_SCOREBOARD
 -D USE_MMAP_FILES
 -D HAVE_FCNTL_SERIALIZED_ACCEPT
 -D HAVE_SYSVSEM_SERIALIZED_ACCEPT
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D HARD_SERVER_LIMIT=256
 -D HTTPD_ROOT="/usr/local/apache"
 -D SUEXEC_BIN="/usr/local/apache/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
 -D ACCESS_CONFIG_FILE="conf/access.conf"
 -D RESOURCE_CONFIG_FILE="conf/srm.conf"

Got a sniffer on the wire too and the output looks like this. The
request is:
GET / HTTP/1.1
Host: testserver
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1)
Gecko/20021003
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0


And the response is:
HTTP/1.1 200 OK
Date: Sat, 19 Jul 2003 20:17:05 GMT
Server: ZipTree
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

1c
Hello World!
You are in main
0


On Sat, 2003-07-19 at 07:34, James Hartling wrote:
> I think Mark had tried it without Apache::Request.  Also, it was obvious at
> some point that he wasn't in a subrequest ($r->is_main returned true, but no
> pnote).   Mark, have you tested $r->notes, and is that working?  I notice
> that your 'marktest' pnote test used a string value.  Perhaps pnotes insists
> on storing refs, not strings - I've never tried it though.  You might also
> start farther back in the request cycle and see if pnotes are being passed
> along at any stage (Init, Access, Fixup, etc).
> 
> Jim
> 
> ----- Original Message -----
> From: "Stas Bekman" <[EMAIL PROTECTED]>
> To: "Mark Maunder" <[EMAIL PROTECTED]>
> Cc: "James Hartling" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Saturday, July 19, 2003 4:55 AM
> Subject: Re: does pnotes() work at all in 1.27?
> 
> 
> > Mark Maunder wrote:
> > > Hi Stas,
> > >
> > > Thanks for the input. Tried that and no luck. I tried using ->instance()
> > > instead of ->new() in both handlers, and it didn't work. Just for kicks
> > > I tried using a few combinations of new() and instance() and no go there
> > > either. I also checked that I had the main request using is_main just to
> > > be safe after retreiving the existing Apache::Request instance.
> >
> > What happens if you remove Apache::Request altogether and try 2 simple
> > handlers, e.g. response handler and logging handler. Does that setup work
> for
> > you? If it does, it has something to do with Apache::Request and not
> mod_perl
> > per se.
> >
> > > I'm going to upgrade to 1.28 in a coupla days so hopefully that'll solve
> > > it. wierd that noone seems to have reported this. The server I'm using
> > > is a stock RH 8.0 server - I dont run redcarpet or anything like that,
> > > and I've only upgraded the minimum to keep it secure. I'm no C
> > > developer, just a perl geek, but I was wondering where pnotes() stores
> > > it's data. In an Apache::Table object? Is there a way for me to manually
> > > access the store somehow at various phases to figure out where the data
> > > gets deleted? Any suggestions would help.
> >
> > You can debug on the C level.
> >
> >
> > __________________________________________________________________
> > Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
> > http://stason.org/     mod_perl Guide ---> http://perl.apache.org
> > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> > http://modperlbook.org http://apache.org   http://ticketmaster.com
> >
-- 
Mark Maunder <[EMAIL PROTECTED]>
ZipTree Inc.

Reply via email to