Re: Using modperl as an 'adaptor' front end to an app server.
Yo ho ho > > However, it wasn't a full implementation of the adaptor and didn't work with > > KeepAlive requests and so forth. > > Hmm.. given the source to the adaptor, and being able to turn debugging > on, it looks pretty simple. Absolutely... we'd need to sift thru the adaptor source and piece together something that emulates it. My version was purely to sniff traffic to see what was going between Apache and the WO apps. > > I have often dreamt of writing a drop-in mod_perl replacement for the WO > > adaptor... I have never worked anywhere where they didn't have trouble > > configuring the Apache adaptor, particularly if their webservers were running > > Linux. If you're interested in pursuing this, drop me a line and we can jam > > on the topic for a bit. I also know the guy who wrote the hairy C code and > > he might have some insight into how to reimplement it. > > Will do. Would that happen to be Steve Quirk? You got it. I am quite serious about getting it to work. WO 4.5 is a different beast from 4.0, though, with the introduction of wotaskd. Still, it's all XML-based so maybe we can leverage a lot of what's out there to get it up and running. Man, it'd be great to have a mod_perl adaptor. Minimise the number of postings to the WO mailing list about getting the stupid adaptor to work, at any rate. :-) Cheerz Kyle -- kyle dawkins [EMAIL PROTECTED]
Re: seg fault with Apache::URI ... weird
er, Test.pm is a ... test script. The seg fault presented itself in real code :) ~~~ Nick Tonkin On Sun, 4 Feb 2001, G.W. Haywood wrote: > Hi there, > > On Sun, 4 Feb 2001, Nick Tonkin wrote: > > > I am encountering a weird problem with Apache::URI ... consider, please, > > this test handler: > > > > package WM::Test; > [snip] > > > As written, this causes a seg fault every time. > > I know this will sound strange, but would you, just for me, try > calling the package something else other than "Test"? That cured > a segfaulting mod_perl on Solaris for me last year. I never had > the time to investigate why that fixed it. You probably won't want > it to be called "Test" eventually anyway... > > 73, > Ged. > >
Re: seg fault with Apache::URI ... weird
Hi there, On Sun, 4 Feb 2001, Nick Tonkin wrote: > I am encountering a weird problem with Apache::URI ... consider, please, > this test handler: > > package WM::Test; [snip] > As written, this causes a seg fault every time. I know this will sound strange, but would you, just for me, try calling the package something else other than "Test"? That cured a segfaulting mod_perl on Solaris for me last year. I never had the time to investigate why that fixed it. You probably won't want it to be called "Test" eventually anyway... 73, Ged.
seg fault with Apache::URI ... weird
Hi all,
I am encountering a weird problem with Apache::URI ... consider, please,
this test handler:
package WM::Test;
use strict;
sub handler {
my $r = shift;
my $uri = Apache::URI->parse($r, $r->uri);
$uri->hostname($r->get_server_name);
$uri->port($r->get_server_port);
print $uri->unparse;
}
1;
__END__
As written, this causes a seg fault every time. Commenting out _either_
the $uri->hostname assignment _or_ the $uri->port assignment solves the
problem, or even changing the call to one or other of the methods from an
assignment to a read. But when both methods are assigned new values, seg
fault.
This code has worked fine for two years or more on my FreeBSD boxes; this
is on Linux RedHat 7 ... dunno if that makes a difference.
apache etc.:
[Sun Feb 4 10:53:11 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.25
mod_ssl/2.8.0 OpenSSL/0.9.6 configured -- resuming normal operations
perl:
wm@wm ~/wm/perl/WM>perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.2.16-22, archname=i686-linux
uname='linux wm 2.2.16-22 #1 tue aug 22 16:49:06 edt 2000 i686 unknown
'
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='gcc', optimize='-O2', gccversion=2.96 2731 (Red Hat Linux 7.0)
cppflags='-fno-strict-aliasing'
ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldl -lm -lc -lcrypt
libc=/lib/libc-2.1.92.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Jan 30 2001 10:41:19
@INC:
/usr/local/lib/perl5/5.6.0/i686-linux
/usr/local/lib/perl5/5.6.0
/usr/local/lib/perl5/site_perl/5.6.0/i686-linux
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl
.
Thanks,
Nick
~~~
Nick Tonkin
