Re: speed up/load balancing of session-based sites
Autarch wrote: > > On Mon, 8 May 2000, Perrin Harkins wrote: > > > Some apps that use Apache::Session, like Embperl and Mason, have chosen > > to rely on cookies. They implement the cookie part themselves. > > Apache::Session has nothing to do with cookies. > > I don't know about Embperl but Mason a) doesn't do anything with > Apache::Session at all if you don't make it do it yourself; and b) doesn't > require you to use cookies if you do. Yeah, I know, I was just oversimplifying a bit. I should have said the example session-handling code that comes with Mason uses cookies. - Perrin
Re: speed up/load balancing of session-based sites
On Mon, 8 May 2000, Perrin Harkins wrote: > Some apps that use Apache::Session, like Embperl and Mason, have chosen > to rely on cookies. They implement the cookie part themselves. > Apache::Session has nothing to do with cookies. I don't know about Embperl but Mason a) doesn't do anything with Apache::Session at all if you don't make it do it yourself; and b) doesn't require you to use cookies if you do. -dave /*== www.urth.org We await the New Sun ==*/
Re: speed up/load balancing of session-based sites
indrek siitan wrote: > > As far as I knew Apache::Session has never even had anything to > > do with cookies. It is a persistent storage mechanism where the > > session "handle" is uniquely generated ID. > > and where do you think the session ID is kept? > > yup. right. in a cookie. Well, no, actually. As Gunther said, Apache::Session doesn't care how you make the session ID persistent. You could use cookies, or path info, or hidden fields, or some crazy DNS mechanism. Apache::Session doesn't know anything about any of those - it requires you to retrieve the ID from the request yourself and pass it along. Some apps that use Apache::Session, like Embperl and Mason, have chosen to rely on cookies. They implement the cookie part themselves. Apache::Session has nothing to do with cookies. - Perrin
RE: speed up/load balancing of session-based sites
Hi, > As far as I knew Apache::Session has never even had anything to > do with cookies. It is a persistent storage mechanism where the > session "handle" is uniquely generated ID. and where do you think the session ID is kept? yup. right. in a cookie. Rgds, Tfr --==< [EMAIL PROTECTED] >==< http://tfr.cafe.ee/ >==< +1-504-4467425 >==--
Re: speed up/load balancing of session-based sites
At 10:13 PM 5/8/00 +0100, Greg Cope wrote: >: On Mon, 8 May 2000, Leslie Mikesell wrote: >: >: > According to Jeffrey W. Baker: >: > >: > > > I keep meaning to write this up as an Apache:: module, but it's >pretty trivial >: > > > to cons up an application-specific version. The only thing this >doesn't >: > > > provide is a way to deal with large data structures. But generally >if the >: > > > application is big enough to need such data structures you have a >real >: > > > database from which you can reconstruct the data on each request, >just store >: > > > the state information in the cookie. >: > > >: > > Your post does a significant amount of hand waving regarding people's >: > > requirements for their websites. I try to keep an open mind when >giving >: > > advice and realize that people all have different needs. That's why I >: > > prefixed my advice with "On my sites..." >: > >: > Can anyone quantify this a bit? >: > >: > > On my sites, I use the session as a general purpose data sink. I find >: > > that I can significantly improve user experience by keeping things in >the >: > > session related to the user-site interaction. These session object >: > > contain way more information than could be stuffed into a cookie, even >if >: > > I assumed that all of my users had cookies turned on. Note also that >: > > sending a large cookie can significantly increase the size of the >: > > request. That's bad for modem users. >: > > >: > > Your site may be different. In fact, it had better be! :) >: > >: > Have you timed your session object retrieval and the cleanup code >: > that becomes necessary with server-session data compared to >: > letting the client send back (via cookies or URL) everything you >: > need to reconstruct the necessary state without keeping temporary >: > session variables on the server? There must be some size where >: > the data values are as easy to pass as the session key, and some >: > size where it becomes slower and more cumbersome. Has anyone >: > pinned down the size where a server-side lookup starts to win? >: >: I have really extensive benchmarks for every part of Apache::Session. >: These will be released with version 1.5, which also includes more than >: fifty new unit tests. Again the performance is very dependent on what you >: are doing. If everything is on one machine and you are grabbing Storable >: obejcts from the filesystem, you can retrieve and unStorable the object in >: time on the order of 100 microseconds (600 MHz Intel/Linux 2.2). If you >: need to get the object out of a database across the network, network >: latency will add to that. In larger applications, I would use a private, >: switch 100 Mb/s ethernet to access the shared backing store, so that >: latency is not bad. Once again, it depends on your specific needs and >: implementation. > >Butting in a little OT here but will v1.5 support the transparent use of >additional path if cookies are turned off. As far as I knew Apache::Session has never even had anything to do with cookies. It is a persistent storage mechanism where the session "handle" is a uniquely generated ID. What you are interested in is a Session "manager" which understands how to deal with the workflow around using a persistent storage mechanism. If you want to play with a sample set of modules to do this you may visit http://www.extropia.com/ExtropiaObjects/ The SessionManager code hierarchy provides plug and play cookie, path info, and hidden form variable session managers that wrap around a session hierarchy (of which 90% is wrapped around Apache::Session as the persistent storage mechanism). SessionManager's belong in a different hierarchy than Session because you don't want to couple the storage mechanism to the type of data... eg Someone may want cookies with file based essions, another person might want path info with database sessions, and yet another person might want a cookie based session with database storage. etc... I suspect it would not necessarily be too hard to write a subclass that would attempt to check the cookie and if it did not exist, to use another existing SessionManager to obtain the Session handle behind the scenes if that is what you are referring to? >The reason for asking is that other web technologies have this sort of >functionality and this would be a great plus for mod_perl (I know it does >not need it, and this can be easily writen..). Agreed. Servlets for one support URL rewriting if cookies are turned off. I don't think Microsoft ASPs support non-cookie based sessions, but I could be wrong. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: growing processes
> You're probably doing something that is causing certain variables to have > temporarily large values. As always, start with the guide: > > http://perl.apache.org/guide/performance.html#Memory_leakage > > You should also make sure you're doing the usual pre-loading and other > suggestions from this section of the guide. You may find the section in > the camel book on optimizing for size useful as well. > > -Perrin The issue of growing (but never shrinking) processes comes up frequently. I saw a nice explanation of why perl can not return memory no longer needed in the Perl Cookbook: Freed memory is returned to Perl for later use, but few operating systems reclaim it and decrease the process's memory footprint. This is because most memory allocators use a stack, and if you free up memory in the middle of the stack, the operating system can't take it back without moving the rest of the allocated memory around. That would destroy the integrity of your pointers and blow XS code out of the water. http://www.oreilly.com/catalog/cookbook/ Slightly related: Is it possible/desirable to have to have perl allocate memory in a certain range? Perhaps within a previously allocated shared mem area? Assuming you delt with the locking issues, it seems that you could share one "scratch" space among a number of processes. -Tim
Re: Am I Defeating The Purpose?
On Mon, 8 May 2000, Pierre J. Nicolas wrote: > I've been tyring for the past several days to stop the > infamous "Undefined Subroutine" messages. I implemented > "solution 2" by adding a "require" statement in all of my scripts. > That still didn't do it. Why do you have this problem in the first place? Is it because you have to use some libraries written in perl4 style, without packages? > However, I just started using "do" and everything is working fine now. > I know that "do" unconditionaly re-loads and re-compiles the perl > script, but I wondering does a script still benefit from "mod_perl" > if it uses "do" to load the perl libraries that it uses. You always beenfit from using mod_perl over CGI, because you avoid forking perl. However, the speedup from keeping the compiled code in memory is pretty big, and well worth the trouble on a busy site. > Also, are the "do" scripts reloaded for each request or is it only once > per unique script invocation. They're re-loaded on each request, which is what makes "do" so painful. If you really can't change your libraries to use packages (and export symbols if necessary), you could at least put the do statement inside a BEGIN block so that it will only happen once per script. You still waste memory by loading the same library multiple times, but you do get the performance benefits. - Perrin
Re: growing processes
On Mon, 8 May 2000, Wim Kerkhoff wrote: > On a fresh restart of apache, my processes are about 20 ~ 25 MB each, > which is about normal for mod_perl (as far as I know). However, > within a few hours (with little use except by our development team), > the size is up to 40MB, and by the end of the day up to 60, 70, even > 90MB each. You're probably doing something that is causing certain variables to have temporarily large values. As always, start with the guide: http://perl.apache.org/guide/performance.html#Memory_leakage You should also make sure you're doing the usual pre-loading and other suggestions from this section of the guide. You may find the section in the camel book on optimizing for size useful as well. - Perrin
Re: speed up/load balancing of session-based sites
On Mon, 8 May 2000, Leslie Mikesell wrote: > > On my sites, I use the session as a general purpose data sink. I find > > that I can significantly improve user experience by keeping things in the > > session related to the user-site interaction. These session object > > contain way more information than could be stuffed into a cookie, even if > > I assumed that all of my users had cookies turned on. Note also that > > sending a large cookie can significantly increase the size of the > > request. That's bad for modem users. > > > > Your site may be different. In fact, it had better be! :) > > Have you timed your session object retrieval and the cleanup code > that becomes necessary with server-session data compared to > letting the client send back (via cookies or URL) everything you > need to reconstruct the necessary state without keeping temporary > session variables on the server? There must be some size where > the data values are as easy to pass as the session key, and some > size where it becomes slower and more cumbersome. Has anyone > pinned down the size where a server-side lookup starts to win? I can't imagine why anyone would pin a website's future to a session system that has a maximum of 1k or 2k of session storage potential! We use a custom written session handler that uses Storable for serialization. We're storing complete results for complex select statements on pages that require "paging" so that the complex select only happens once. We store user objects complete, and many multi-level complex data structures at whim. Limiting yourself to cookie size limitation would be a real drag. -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: growing processes
Not strange, a memory leak. You've got some bad code. If you have a program that you've been twiddling with recently, that would be the place to start looking. --Jeff At 09:34 AM 5/8/00, Wim Kerkhoff wrote: >I'm running into something kind of strange... > >On a fresh restart of apache, my processes are about 20 ~ 25 MB each, which is >about normal for mod_perl (as far as I know). However, within a few hours >(with little use except by our development team), the size is up to 40MB, and >by the end of the day up to 60, 70, even 90MB each. > >I highly doubt this is normal... Where do I start to track down the cause >of it? > >I'm using Apache::DBI and HTML::Embperl. > >Server: Apache/1.3.9 (Unix) Debian/GNU mod_perl/1.21_03-dev mod_ssl/2.4.10 >OpenSSL/0.9.4 > >Linux dev 2.2.12 #2 Thu Aug 26 11:46:26 PDT 1999 i686 unknown > >Thanks, > >Wim Kerkhoff, Software Engineer >NetMaster Networking Solutions >[EMAIL PROTECTED] Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: Core dump: Solaris 2.7/mod_perl1.23/Apache1.3.12/perl5.6.0
Some more info: I've rebuilt everything with debug, and the SEGV is
happening in mod_perl.c in the following code:
#ifdef PERL_HEADER_PARSER
int PERL_HEADER_PARSER_HOOK(request_rec *r)
{
dSTATUS;
dPPDIR;
#ifdef PERL_INIT
PERL_CALLBACK("PerlInitHandler",
cld->PerlInitHandler);
#endif
PERL_CALLBACK("PerlHeaderParserHandler",
cld->PerlHeaderParserHandler);
return status;
}
#endif
specifically the macro dPPDIR. I notice that the request_rec pointer
passed in has one field that points to an invalid address, I don't know
if it is relevant:
parsed_uri= {
scheme = (nil)
hostinfo = (nil)
user = 0x174fa0 "/"
password = (nil)
hostname = (nil)
port_str = (nil)
path = 0x8000 ""
query = 0x175418 ""
fragment = 0x174e20 ""
hostent= 0x1755a0
port = 23U
is_initialized = 0
dns_looked_up = 1U
dns_resolved = 0
expanding out dPPDIR it refers to r->per_dir_config and &perl_module.
r->per_dir_config is a void*, and has the value 8, which sure doesn't
look like a valid address to me. perl_module on the other hand all
looks sane. I'm not sure where to look next - any suggestions?
--
Alan Burlison
Re: Core dump: Solaris 2.7/mod_perl1.23/Apache1.3.12/perl5.6.0
Alan Burlison <[EMAIL PROTECTED]> writes: > This is a new one on me. mod_perl is built with APXS and perl is built > with -DDL_UNLOAD_ALL_AT_EXIT, so it isn't coredumping during startup, > but it cores the first time an access is made. Anyone have any > suggestions? > > =>[1] perl_header_parser(0xd9480, 0xff16ca04, 0xa, 0xd9480, 0x2f707269, > 0x2f617061), at 0xff124acc > [2] run_method(0xd9480, 0x74, 0x8f764, 0x1, 0xda4e8, 0x4), at 0x32828 > [3] process_request_internal(0xd9480, 0xff0c, 0xd9480, 0xd8440, > 0xd9608, 0x40090), at 0x44d74 > [4] ap_process_request(0x89000, 0xd9480, 0xd9480, 0xff0c, 0x0, > 0x4), at 0x45090 > [5] child_main(0x8f800, 0x8f800, 0xd9480, 0x0, 0x0, 0x0), at 0x3d0d0 > [6] make_child(0x943d0, 0x0, 0x3916cee9, 0x943d0, 0x0, 0x0), at > 0x3d2b8 > [7] startup_children(0x8f988, 0x8d048, 0x8902c, 0x3916cee9, 0x0, 0x0), > at 0x3d42c > [8] standalone_main(0x8f800, 0x8f800, 0x8f824, 0xa912c, 0xb400, 0x8), > at 0x3da64 > [9] main(0x8f800, 0x8f800, 0x2, 0x88400, 0x0, 0x0), at 0x3e348 No suggestions, but the same thing happened to me with the same software versions except on Solaris 2.6. As the DSO functionality is marked as experimental, I gave up and did a static compile of mod_perl into the Apache binary. -- Dan Harkless [EMAIL PROTECTED]
Re: speed up/load balancing of session-based sites
: On Mon, 8 May 2000, Leslie Mikesell wrote: : : > According to Jeffrey W. Baker: : > : > > > I keep meaning to write this up as an Apache:: module, but it's pretty trivial : > > > to cons up an application-specific version. The only thing this doesn't : > > > provide is a way to deal with large data structures. But generally if the : > > > application is big enough to need such data structures you have a real : > > > database from which you can reconstruct the data on each request, just store : > > > the state information in the cookie. : > > : > > Your post does a significant amount of hand waving regarding people's : > > requirements for their websites. I try to keep an open mind when giving : > > advice and realize that people all have different needs. That's why I : > > prefixed my advice with "On my sites..." : > : > Can anyone quantify this a bit? : > : > > On my sites, I use the session as a general purpose data sink. I find : > > that I can significantly improve user experience by keeping things in the : > > session related to the user-site interaction. These session object : > > contain way more information than could be stuffed into a cookie, even if : > > I assumed that all of my users had cookies turned on. Note also that : > > sending a large cookie can significantly increase the size of the : > > request. That's bad for modem users. : > > : > > Your site may be different. In fact, it had better be! :) : > : > Have you timed your session object retrieval and the cleanup code : > that becomes necessary with server-session data compared to : > letting the client send back (via cookies or URL) everything you : > need to reconstruct the necessary state without keeping temporary : > session variables on the server? There must be some size where : > the data values are as easy to pass as the session key, and some : > size where it becomes slower and more cumbersome. Has anyone : > pinned down the size where a server-side lookup starts to win? : : I have really extensive benchmarks for every part of Apache::Session. : These will be released with version 1.5, which also includes more than : fifty new unit tests. Again the performance is very dependent on what you : are doing. If everything is on one machine and you are grabbing Storable : obejcts from the filesystem, you can retrieve and unStorable the object in : time on the order of 100 microseconds (600 MHz Intel/Linux 2.2). If you : need to get the object out of a database across the network, network : latency will add to that. In larger applications, I would use a private, : switch 100 Mb/s ethernet to access the shared backing store, so that : latency is not bad. Once again, it depends on your specific needs and : implementation. Butting in a little OT here but will v1.5 support the transparent use of additional path if cookies are turned off. The reason for asking is that other web technologies have this sort of functionality and this would be a great plus for mod_perl (I know it does not need it, and this can be easily writen..). Greg Cope
Re: "make test" fails, httpd fails to start
--On Monday, May 08, 2000 12:15 PM -0500 Steve Bauer <[EMAIL PROTECTED]> wrote: > I have apache 1.3.12, and mod_perl 1.23. both apache and mod_perl build > successfully, but make test fails. the output from "make test" is: > > cp t/conf/mod_perl_srm.conf t/conf/srm.conf > ../apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & > httpd listening on port 8529 > will write error_log to: t/logs/error_log > Syntax error on line 3 of /tmp/mod_perl-1.23/t/conf/httpd.conf: > Invalid command '=pod', perhaps mis-spelled or defined by a module not > included in the server configuration > letting apache warm up...done > /usr/local/bin/perl t/TEST 0 > still waiting for server to warm up...not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line > 95. > *** Error code 146 > make: Fatal error: Command failed for target `run_tests' > > > The file /t/httpd.conf contain several pod commands. > > Anybody have any ideas of where to look or how to fix this?? > > Steve Bauer > Cyber Database Solutions. Steve, Assuming your problem and the one I posted several weeks ago are the same, the cause and solution are self-evident -- but only after the fact (perhaps we should call it post-self-evident, "pse" for short :-) In my case, I had a fresh Apache and I built mod_perl without building Apache. That would be a fairly normal thing to do if you want to add modules besides mod_perl, and it's a correct procedure according to the documentation. There is a fundamental flaw, however, in both the documentation and the procedure: If you haven't build Apavhe, there is no httpd executable in the Apache source tree. Everything tested as advertised only when I first built mod_perl and installed it in the Apache source tree, then built Apache with the mod_perl libraries, and then went back and did the test for mod_perl. All tests passed without a hitch. I installed Apache, and using the example in the O'Reilly book (can't remember which critter is on the cover), wrote the obligatory "Hello World", and was on my way. -- Rob _ _ _ _ __ _ _ _ _ /\_\_\_\_\/\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_//\/_/ /\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon [EMAIL PROTECTED]
Re: apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1, OpenSSL0.9.4, modssl
CN=Jeff [EMAIL PROTECTED] on 05/08/2000 03:43:00 PM Sent by: [EMAIL PROTECTED] Sent From the mail file of: Jeff Bulley To: [EMAIL PROTECTED] cc: Subject: Re: apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1, OpenSSL0.9.4, modssl >Hmm. >We've had very different relations to the Open Source >Community. They've been swell to me. >5.6.0 is not ready for prime time. >I have noticed that some open sourcers refuse to answer >or even respond to porn dealers. But other than that >(which is a moral guideline and not some corporate privacy >policy) I have found them nice. Unless there's some bizarre misconception out there I don't think this is a problem (g). >Plus, the source code is open and freely available. Which >is all Open Source inherently promises. Poor choice of words on my part. I just felt that the time I spent narrowing down the problem to the best of my ability would help the effort toward resolution. The dead silence I ran into I found quite surprising. I felt I would have gotten a better response if I would have played dumb and said "I can't get it to work help me fix it". Instead it seems that by narrowing the scope of the problem I cut myself off from assitance.
Re: growing processes
On 08-May-2000 [EMAIL PROTECTED] wrote: > I AM NOT AN EXPERT. Which is why I didn't post to the list. > I just happened to notice your question, and since everyone > seems to be out to lunch, I though I'd give it a whack. Thanks... I'm a quite new to mod_perl as well, and on some of the things I have no idea what is "normal". > They are probably going to suggest GTop::Limit to you. > I think Doug wrote it. > You can kill the Apache children after they service, say, > 50 requests or the amount of shared memory they are using > gets to low. > > I think it is real easy to kill after 50 requests with > MaxRequestsPerChild, but GTop::Limit has more flexibility. I can do this and it would could probably fix my problem, but I have a feeling that each process should be able to handle more than 50 requests. I could be way of track though... I just examined top again... in the time it took to punch out this email and do some other things (maybe 20 minutes), each process was up to 139 MB, although SHARE was 132MB. That would mean 5 MB is unshared which isn't bad... It seems to me like something else is up here. > Enjoy. Thanks for the reply! Wim Kerkhoff, Software Engineer NetMaster Networking Solutions [EMAIL PROTECTED]
Re: speed up/load balancing of session-based sites
On Mon, 8 May 2000, Leslie Mikesell wrote: > According to Jeffrey W. Baker: > > > > I keep meaning to write this up as an Apache:: module, but it's pretty trivial > > > to cons up an application-specific version. The only thing this doesn't > > > provide is a way to deal with large data structures. But generally if the > > > application is big enough to need such data structures you have a real > > > database from which you can reconstruct the data on each request, just store > > > the state information in the cookie. > > > > Your post does a significant amount of hand waving regarding people's > > requirements for their websites. I try to keep an open mind when giving > > advice and realize that people all have different needs. That's why I > > prefixed my advice with "On my sites..." > > Can anyone quantify this a bit? > > > On my sites, I use the session as a general purpose data sink. I find > > that I can significantly improve user experience by keeping things in the > > session related to the user-site interaction. These session object > > contain way more information than could be stuffed into a cookie, even if > > I assumed that all of my users had cookies turned on. Note also that > > sending a large cookie can significantly increase the size of the > > request. That's bad for modem users. > > > > Your site may be different. In fact, it had better be! :) > > Have you timed your session object retrieval and the cleanup code > that becomes necessary with server-session data compared to > letting the client send back (via cookies or URL) everything you > need to reconstruct the necessary state without keeping temporary > session variables on the server? There must be some size where > the data values are as easy to pass as the session key, and some > size where it becomes slower and more cumbersome. Has anyone > pinned down the size where a server-side lookup starts to win? I have really extensive benchmarks for every part of Apache::Session. These will be released with version 1.5, which also includes more than fifty new unit tests. Again the performance is very dependent on what you are doing. If everything is on one machine and you are grabbing Storable obejcts from the filesystem, you can retrieve and unStorable the object in time on the order of 100 microseconds (600 MHz Intel/Linux 2.2). If you need to get the object out of a database across the network, network latency will add to that. In larger applications, I would use a private, switch 100 Mb/s ethernet to access the shared backing store, so that latency is not bad. Once again, it depends on your specific needs and implementation. I think storing the state information in a cookie is fine, if you can do it. For me, the state information is larger than what you can shove into a cookie, according to the cookie specification. It simply is not an option for me. I also don't think the cookie storage mechanism is the best thing for the users. If I store the session information on the server side, I can do some pretty tricky stuff. The user could use one computer for a while, go somewhere else, then log in from another computer and I could take him right back to whatever he was doing before. With cookie storage, you can't do that. -jwb
Re: apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1, OpenSSL0.9.4, modssl
I've expirienced similar problems on Solaris (2.6). After a weeks worth of hours I feel confidant saying that the instability is from perl 5.6.0 NOT from mod_perl(1.23) Problems resulting from the Sys::Syslog created problems for other modules that relied on things like Net::Daemon and PlRPC moduless. Module authors I contacted only did work arounds. comp.lang.perl.moderated didn't even post the problems I was having. I never got past those issues to the numerous other strange errors that were cropping up everywhere. So after losing a weeks worth of hours I gave up in retreat. Dropping my perl version to 5.005_03 and rebuilding everything seems to have restored stability (and my sanity). I'd just like to say that in this regard I didn't find Open Source very Open. In fact things seemed quite corporate with the newsgroups and mailing lists saying "off topic for here" or even failing to post legitimate questions. These products are getting so intertwined the definition of what topic belongs where begins to get mighty grey. Then again maybe I just didn't read enough FAQs to ask the question the right way. I'm not wanting to start a flame war, just reporting it as I see it. IMHO Solaris(2.6)Perl(5.6) just isn't fully cooked yet. Jeff CN=Jeff [EMAIL PROTECTED]> on 05/08/2000 06:48:12 AM Sent by: Thomas Apsel <[EMAIL PROTECTED]> Sent From the mail file of: Jeff Bulley To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1, OpenSSL0.9.4, modssl Hi, I am building an apache web server for serveral operating systems: Solaris, HPUX, AIX and Windows NT. My apache is based on: apache_1.3.12/ openssl-0.9.4/ mod_ssl-2.6.2-1.3.12/ ApacheJServ-1.1/ mod_perl-1.23/ perl-5.6.0/ I have an older one, which is based on mod_perl-1.22 and perl-5.005_03. This version works very fine on all platforms. After I have upgrade to mod_perl-1.23 and perl-5.6.0 my apache crashes on Solaris (mod_perl works fine, but if I try to start a servlet via ApacheJServ I get a segmentation violation). Then I build the apache without mod_perl-1.23. This version works fine, my servlets are processed via the servlet engine in the apache. I think, that mod_perl-1.23 does something wrong, but I have no idea. On Windows NT my new apache works fine. I build mod_perl with Makefile.PL APACHE_SRC=../apache_1.3.12/src \ DO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 Have anyone experiences with this apache configuration? Can anyone help me? Thomas Thomas Apsel mailto:[EMAIL PROTECTED] IXOS SOFTWARE AG Tel.: +49.(0)89.4629.1817 Bretonischer Ring 12 Fax.: +49.(0)89.4629.33.1817 D-85630 Grasbrunn http://www.ixos.de http://www.or.uni-passau.de/~apsel
Re: speed up/load balancing of session-based sites
On Mon, 8 May 2000, Adi wrote: > Leslie Mikesell wrote: > > > > According to Jeffrey W. Baker: > > > > > > I keep meaning to write this up as an Apache:: module, but it's pretty trivial > > > > to cons up an application-specific version. The only thing this doesn't > > > > provide is a way to deal with large data structures. But generally if the > > > > application is big enough to need such data structures you have a real > > > > database from which you can reconstruct the data on each request, just store > > > > the state information in the cookie. > > > > > > Your post does a significant amount of hand waving regarding people's > > > requirements for their websites. I try to keep an open mind when giving > > > advice and realize that people all have different needs. That's why I > > > prefixed my advice with "On my sites..." > > > > Can anyone quantify this a bit? > > On my site, I *need* to use server-side session objects. I am storing data > that the user should not be allowed to modify. The session data is used > directly by the server to determine what data to send to users in different > cases. If it were passed in the cookie, a malicious user could take > advantage of this and change the state of their session at will. If you also include a cryptographic hash of the cookie contents, the user will not be able to successfully modify the cookie. Your application must check and generate the hash on every request, and you would also need to invent some kind of secret management system (because the contents of the cookie are hashed with some secret string). -jwb
Re: "make test" fails, httpd fails to start
On Mon, 8 May 2000, Steve Bauer wrote: > The file t/logs/error_log is never created. httpd fails because > /t/conf/httpd.conf looks more like a pod file than a httpd.conf. That's fine. > How is the correct httpd.conf file supposed to be created? > > What can I do to determine why the creation is not happening?? May be file permissions? Or the user/group selection for the child to run under. > Steve Bauer > > Stas Bekman wrote: > > > > On Mon, 8 May 2000, Steve Bauer wrote: > > > > > I have apache 1.3.12, and mod_perl 1.23. both apache and mod_perl build > > > successfully, but make test fails. the output from "make test" is: > > > > > > cp t/conf/mod_perl_srm.conf t/conf/srm.conf > > httpd fails to start because of the following. > > > will write error_log to: t/logs/error_log > > > Syntax error on line 3 of /tmp/mod_perl-1.23/t/conf/httpd.conf: > > > Invalid command '=pod', perhaps mis-spelled or defined by a module not > > > included in the server configuration > > > letting apache warm up...done > > > /usr/local/bin/perl t/TEST 0 > > > still waiting for server to warm up...not ok > > > server failed to start! (please examine t/logs/error_log) at t/TEST line > > > 95. > > > *** Error code 146 > > > make: Fatal error: Command failed for target `run_tests' > > > > Yeah, how about: > > > server failed to start! (please examine t/logs/error_log) at t/TEST line > >^^^ > > > 95. > > > > > > > > > > > The file /t/httpd.conf contain several pod commands. > > > > > > Anybody have any ideas of where to look or how to fix this?? > > > > > > Steve Bauer > > > Cyber Database Solutions. > > > > > > > __ > > Stas Bekman | JAm_pH--Just Another mod_perl Hacker > > http://stason.org/ | mod_perl Guide http://perl.apache.org/guide > > mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ > > http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org > > -- > __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
ANNOUNCE: HTML::Mason 0.85
The URL http://www.masonhq.com/download/HTML-Mason-0.85.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JS/JSWARTZ/HTML-Mason-0.85.tar.gz size: 256559 bytes md5: 430067fc80d7194292b4e5c00f01da2b Mason is a component-based web site development system with caching, debugging, and previewing facilities. Check out http://www.masonhq.com for more information. This release introduces more powerful templates and basic object-oriented primitives for components. Templates can easily access methods and attributes on the current page for greater flexibility. Templates are now recursive and cascading by default. Other changes: - Integrated a revamped parse_component that is cleaner, more modular and easier to subclass. Courtesy of Dave Rolsky. - New <%shared> section contains code that executes once per request and whose declarations are visible from the main component, methods and subcomponents alike. - Added escape flags for <% %> output. Can now HTML-escape or URI-escape expressions on a site-wide or per-expression basis. - Added choice of CGI or Apache::Request when using ApacheHandler. (submitted by Dave Rolsky) - Documented $m->clear_buffer, which removes all pending output from the buffer. - Fixed keys and expires cache actions from m->cache interface. (suggested by Matt Hoskins) - dhandlers can now serve their own directory; added documentation about handling directories. - Fixed dhandler bug introduced in 0.81 whereby $m->dhandler_arg only contains the first branch of a multi-branch argument. - Removed memory leak in ApacheHandler::handle_request_1. (submitted by Pascal Eeftinck and Renzo Toma) - Changed parent_comp() to owner() for subcomponents/methods. - Increased maximum recurse level from 16 to 32. - Reorganized syntax section of developer's manual and added a "how to use this manual" section. - Added an UPGRADE guide to distribution. - Added section about securing top-level components to Admin.pod. (suggested by Sean Cazzell) - Added section about declining image requests to Admin.pod. - Eliminated "Subroutine status_mason redefined" warning when creating multiple ApacheHandlers. - Updated cookie expiration in CD-ME example. (reported by Renzo Toma) - Added a "-f" flag to rm in faq Makefile. (reported by Jeremy Taylor)
Re: "make test" fails, httpd fails to start
The file t/logs/error_log is never created. httpd fails because /t/conf/httpd.conf looks more like a pod file than a httpd.conf. How is the correct httpd.conf file supposed to be created? What can I do to determine why the creation is not happening?? Steve Bauer Stas Bekman wrote: > > On Mon, 8 May 2000, Steve Bauer wrote: > > > I have apache 1.3.12, and mod_perl 1.23. both apache and mod_perl build > > successfully, but make test fails. the output from "make test" is: > > > > cp t/conf/mod_perl_srm.conf t/conf/srm.conf httpd fails to start because of the following. > > will write error_log to: t/logs/error_log > > Syntax error on line 3 of /tmp/mod_perl-1.23/t/conf/httpd.conf: > > Invalid command '=pod', perhaps mis-spelled or defined by a module not > > included in the server configuration > > letting apache warm up...done > > /usr/local/bin/perl t/TEST 0 > > still waiting for server to warm up...not ok > > server failed to start! (please examine t/logs/error_log) at t/TEST line > > 95. > > *** Error code 146 > > make: Fatal error: Command failed for target `run_tests' > > Yeah, how about: > > server failed to start! (please examine t/logs/error_log) at t/TEST line >^^^ > > 95. > > > > > > > The file /t/httpd.conf contain several pod commands. > > > > Anybody have any ideas of where to look or how to fix this?? > > > > Steve Bauer > > Cyber Database Solutions. > > > > __ > Stas Bekman | JAm_pH--Just Another mod_perl Hacker > http://stason.org/ | mod_perl Guide http://perl.apache.org/guide > mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ > http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org > --
Re: "make test" fails, httpd fails to start
On Mon, 8 May 2000, Steve Bauer wrote: > I have apache 1.3.12, and mod_perl 1.23. both apache and mod_perl build > successfully, but make test fails. the output from "make test" is: > > cp t/conf/mod_perl_srm.conf t/conf/srm.conf > ../apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & > httpd listening on port 8529 > will write error_log to: t/logs/error_log > Syntax error on line 3 of /tmp/mod_perl-1.23/t/conf/httpd.conf: > Invalid command '=pod', perhaps mis-spelled or defined by a module not > included in the server configuration > letting apache warm up...done > /usr/local/bin/perl t/TEST 0 > still waiting for server to warm up...not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line > 95. > *** Error code 146 > make: Fatal error: Command failed for target `run_tests' Yeah, how about: > server failed to start! (please examine t/logs/error_log) at t/TEST line ^^^ > 95. > > > The file /t/httpd.conf contain several pod commands. > > Anybody have any ideas of where to look or how to fix this?? > > Steve Bauer > Cyber Database Solutions. > __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Session management moudle suggestions?
On Mon, May 08, 2000 at 11:41:39AM -0700, Stephen Zander wrote: > > I've avoided session management like the plague until now (intranets > let you get away with that sort of thing :)) but rolling out web-based > LDAP is forcing session management upon me. > > Other than Apache::Session what are my choices? How well do any of > these play with templating (Embperl, Mason et al)? Apache::ASP has very nice session management capabilities. IMHO The best feature is the Session_OnEnd handler (you can define code that is executed when the Session finishes.) And it's templating is superb. -- Paul Lindner [EMAIL PROTECTED] Red Hat Inc.
Re: Session management moudle suggestions?
We are using HTML::Mason and Apache::Session with great results. Apache::Session::DBI was killing us for some reason but moving it to our network appliance box and Apache::Session:File has really pumped up our performance. When you really start using sessions you can get some cool stuff out of them, we use them for all sorts of read only data now, not just users. Using Mason and Apache::Session has really increased our speed of development. John- At 11:41 AM -0700 5/8/00, Stephen Zander wrote: >I've avoided session management like the plague until now (intranets >let you get away with that sort of thing :)) but rolling out web-based >LDAP is forcing session management upon me. > >Other than Apache::Session what are my choices? How well do any of >these play with templating (Embperl, Mason et al)? > >-- >Stephen > >"So.. if she weighs the same as a duck.. she's made of wood." "And >therefore?" "A witch!"
RE: Session management moudle suggestions?
> I've avoided session management like the plague until now (intranets > let you get away with that sort of thing :)) but rolling out web-based > LDAP is forcing session management upon me. > > Other than Apache::Session what are my choices? Build your own... > How well do any of > these play with templating (Embperl, Mason et al)? > Embperl has build in support for session management via Apache::Session. The only thing you need to do is to put your data in a special hash and Embperl does the rest for you. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Session management moudle suggestions?
I've avoided session management like the plague until now (intranets let you get away with that sort of thing :)) but rolling out web-based LDAP is forcing session management upon me. Other than Apache::Session what are my choices? How well do any of these play with templating (Embperl, Mason et al)? -- Stephen "So.. if she weighs the same as a duck.. she's made of wood." "And therefore?" "A witch!"
Re: speed up/load balancing of session-based sites
Leslie Mikesell wrote: > > According to Jeffrey W. Baker: > > > > I keep meaning to write this up as an Apache:: module, but it's pretty trivial > > > to cons up an application-specific version. The only thing this doesn't > > > provide is a way to deal with large data structures. But generally if the > > > application is big enough to need such data structures you have a real > > > database from which you can reconstruct the data on each request, just store > > > the state information in the cookie. > > > > Your post does a significant amount of hand waving regarding people's > > requirements for their websites. I try to keep an open mind when giving > > advice and realize that people all have different needs. That's why I > > prefixed my advice with "On my sites..." > > Can anyone quantify this a bit? On my site, I *need* to use server-side session objects. I am storing data that the user should not be allowed to modify. The session data is used directly by the server to determine what data to send to users in different cases. If it were passed in the cookie, a malicious user could take advantage of this and change the state of their session at will. -Adi
"make test" fails, httpd fails to start
I have apache 1.3.12, and mod_perl 1.23. both apache and mod_perl build successfully, but make test fails. the output from "make test" is: cp t/conf/mod_perl_srm.conf t/conf/srm.conf ../apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & httpd listening on port 8529 will write error_log to: t/logs/error_log Syntax error on line 3 of /tmp/mod_perl-1.23/t/conf/httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration letting apache warm up...done /usr/local/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. *** Error code 146 make: Fatal error: Command failed for target `run_tests' The file /t/httpd.conf contain several pod commands. Anybody have any ideas of where to look or how to fix this?? Steve Bauer Cyber Database Solutions.
growing processes
I'm running into something kind of strange... On a fresh restart of apache, my processes are about 20 ~ 25 MB each, which is about normal for mod_perl (as far as I know). However, within a few hours (with little use except by our development team), the size is up to 40MB, and by the end of the day up to 60, 70, even 90MB each. I highly doubt this is normal... Where do I start to track down the cause of it? I'm using Apache::DBI and HTML::Embperl. Server: Apache/1.3.9 (Unix) Debian/GNU mod_perl/1.21_03-dev mod_ssl/2.4.10 OpenSSL/0.9.4 Linux dev 2.2.12 #2 Thu Aug 26 11:46:26 PDT 1999 i686 unknown Thanks, Wim Kerkhoff, Software Engineer NetMaster Networking Solutions [EMAIL PROTECTED]
apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1, OpenSSL0.9.4, modssl
Hi, I am building an apache web server for serveral operating systems: Solaris, HPUX, AIX and Windows NT. My apache is based on: apache_1.3.12/ openssl-0.9.4/ mod_ssl-2.6.2-1.3.12/ ApacheJServ-1.1/ mod_perl-1.23/ perl-5.6.0/ I have an older one, which is based on mod_perl-1.22 and perl-5.005_03. This version works very fine on all platforms. After I have upgrade to mod_perl-1.23 and perl-5.6.0 my apache crashes on Solaris (mod_perl works fine, but if I try to start a servlet via ApacheJServ I get a segmentation violation). Then I build the apache without mod_perl-1.23. This version works fine, my servlets are processed via the servlet engine in the apache. I think, that mod_perl-1.23 does something wrong, but I have no idea. On Windows NT my new apache works fine. I build mod_perl with Makefile.PL APACHE_SRC=../apache_1.3.12/src \ DO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 Have anyone experiences with this apache configuration? Can anyone help me? Thomas Thomas Apsel mailto:[EMAIL PROTECTED] IXOS SOFTWARE AG Tel.: +49.(0)89.4629.1817 Bretonischer Ring 12 Fax.: +49.(0)89.4629.33.1817 D-85630 Grasbrunn http://www.ixos.de http://www.or.uni-passau.de/~apsel
Am I Defeating The Purpose?
I've been tyring for the past several days to stop the infamous "Undefined Subroutine" messages. I implemented "solution 2" by adding a "require" statement in all of my scripts. That still didn't do it. However, I just started using "do" and everything is working fine now. I know that "do" unconditionaly re-loads and re-compiles the perl script, but I wondering does a script still benefit from "mod_perl" if it uses "do" to load the perl libraries that it uses. Also, are the "do" scripts reloaded for each request or is it only once per unique script invocation. Thanks, Pierre
Re: speed up/load balancing of session-based sites
According to Jeffrey W. Baker: > > I keep meaning to write this up as an Apache:: module, but it's pretty trivial > > to cons up an application-specific version. The only thing this doesn't > > provide is a way to deal with large data structures. But generally if the > > application is big enough to need such data structures you have a real > > database from which you can reconstruct the data on each request, just store > > the state information in the cookie. > > Your post does a significant amount of hand waving regarding people's > requirements for their websites. I try to keep an open mind when giving > advice and realize that people all have different needs. That's why I > prefixed my advice with "On my sites..." Can anyone quantify this a bit? > On my sites, I use the session as a general purpose data sink. I find > that I can significantly improve user experience by keeping things in the > session related to the user-site interaction. These session object > contain way more information than could be stuffed into a cookie, even if > I assumed that all of my users had cookies turned on. Note also that > sending a large cookie can significantly increase the size of the > request. That's bad for modem users. > > Your site may be different. In fact, it had better be! :) Have you timed your session object retrieval and the cleanup code that becomes necessary with server-session data compared to letting the client send back (via cookies or URL) everything you need to reconstruct the necessary state without keeping temporary session variables on the server? There must be some size where the data values are as easy to pass as the session key, and some size where it becomes slower and more cumbersome. Has anyone pinned down the size where a server-side lookup starts to win? Les Mikesell [EMAIL PROTECTED]
Re: Perl based file upload CGI on Apache server
I'll have to get the code back from the office... but someone told me that Apache has a security feature you have to turn off in order to allow a perl CGI to write to the server when using the file form. Is this true? Brendan McKenna wrote: > > Hi Dave, > > It's hard to tell without the code, but does the program ever > actually write the file? You can read the file via the CGI.pm module, but > you have to write it out yourself... > > Brendan > > : > : I apologize immediately if this is not the proper forum for this > : question, however I have a Perl CGI I am running on a Apache based > : server, and the script is known to work properly however when I look at > : the file it has a size of ZERO...meaning the file name appears in the > : directory it was suppose to be uploaded to. > : > : If you can give me a hint on what went wrong I would greatly appreciate > : it. Thank you. > : > : > : -- > :David Coley > : [EMAIL PROTECTED] > : http://www.davidcoley.com > :Keeping programmers ahead, by sharing the source. > : http://www.codecipher.com > : > > -- > Brendan McKenna > Technical Director Phone: +353-(0)61-338177 x4143 > W3 Services Ltd. Fax: +353-(0)61-338065 > Innovation Centre Email: [EMAIL PROTECTED] > National Technological Park > Limerick > Ireland -- David Coley [EMAIL PROTECTED] http://www.davidcoley.com Keeping programmers ahead, by sharing the source. http://www.codecipher.com
RE: Consolidated Log Files
http://www.virtualschool.edu/lang/perl/CuteTricksPerlApache.html#Logging_to_ syslog o _ /|/ | Jerrad Pierce \ | __|_ _| /||/ http://pthbb.org . | _| | \|| _.-~-._.-~-._.-~-._@" _|\_|___|___|
Consolidated Log Files
We have a setup where an Alpha provided DBMS and content services to the actual web server front-ends. What I would like to know is how I can get all these 4 web servers to write to one log file? Would using something apache DBILogger be the way to go? -ar Angel R. Rivera, [EMAIL PROTECTED] -- Website: http://www.wolf.com Lists: http://www.wolf.com/lists/ Our Wolf: http://www.wolf.com/Ookami.jpg -- "The Quality of a person's life is in direct proportion to their commitment to excellence, regardless of their chosen field of endeavor." Vincent T. Lombardi
Perl based file upload CGI on Apache server
I apologize immediately if this is not the proper forum for this question, however I have a Perl CGI I am running on a Apache based server, and the script is known to work properly however when I look at the file it has a size of ZERO...meaning the file name appears in the directory it was suppose to be uploaded to. If you can give me a hint on what went wrong I would greatly appreciate it. Thank you. -- David Coley [EMAIL PROTECTED] http://www.davidcoley.com Keeping programmers ahead, by sharing the source. http://www.codecipher.com
Re: OT: Re: Most nonesense I've ever read about mod_perl
Matt Sergeant wrote: > On Sun, 7 May 2000, Frank Mayhar wrote: > > Perl does have some good constructs for Web work, too. I've been writing > > a webstore and some stuff is really convenient that would be inconvenient > > in C. On the other hand, there's some stuff that I just wouldn't use Perl > > for, like, say, a system daemon, and there's other stuff that I _can't_ use > > it for, like in the kernel. > Do a web search for perlfs - yes someone really did embed perl into the > Linux kernel ;-) Kill them. Kill them now. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ And I thought _Unixware_ suffered from bloat.
Core dump: Solaris 2.7/mod_perl1.23/Apache1.3.12/perl5.6.0
This is a new one on me. mod_perl is built with APXS and perl is built with -DDL_UNLOAD_ALL_AT_EXIT, so it isn't coredumping during startup, but it cores the first time an access is made. Anyone have any suggestions? =>[1] perl_header_parser(0xd9480, 0xff16ca04, 0xa, 0xd9480, 0x2f707269, 0x2f617061), at 0xff124acc [2] run_method(0xd9480, 0x74, 0x8f764, 0x1, 0xda4e8, 0x4), at 0x32828 [3] process_request_internal(0xd9480, 0xff0c, 0xd9480, 0xd8440, 0xd9608, 0x40090), at 0x44d74 [4] ap_process_request(0x89000, 0xd9480, 0xd9480, 0xff0c, 0x0, 0x4), at 0x45090 [5] child_main(0x8f800, 0x8f800, 0xd9480, 0x0, 0x0, 0x0), at 0x3d0d0 [6] make_child(0x943d0, 0x0, 0x3916cee9, 0x943d0, 0x0, 0x0), at 0x3d2b8 [7] startup_children(0x8f988, 0x8d048, 0x8902c, 0x3916cee9, 0x0, 0x0), at 0x3d42c [8] standalone_main(0x8f800, 0x8f800, 0x8f824, 0xa912c, 0xb400, 0x8), at 0x3da64 [9] main(0x8f800, 0x8f800, 0x2, 0x88400, 0x0, 0x0), at 0x3e348 Alan Burlison
Re: Newbie Question -
Adi wrote: > > Jim Winstead wrote: > > > > On May 05, Adi wrote: > > > You can still use CGI.pm from within mod_perl (and you should). There is > > > nothing better at handling data passed from a browser via HTTP POST and/or > > > GET. If you currently use CGI.pm, I think you'll find that a lot of your > > > current code can simply be cut-and-pasted into a mod_perl setup. > > > > Well, arguably Apache::Request is better at handling data passed > > from a browser via HTTP POST and/or GET in a mod_perl environment. > > And it has the advantage that is entirely focused on request > > handling, and doesn't have any of the HTML generation cruft like > > CGI.pm. > > Wow, I wasn't aware of Apache::Request.. thanks for letting me know. What I would really like is a module which subclasses Apache::Request, and has the popup_menu, scrolling_list, and checkbox group methods available. That way I can use the smaller (faster) Apache::Request and still have the few HTML generation methods that I need. This would be similar to Apache::RequestNotes. One day I'll actually do it when I convert my CGI scripts to perl handlers... -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: PerlAddVar ?
Stas Bekman wrote:
>
> > > Cool! I guess it's a non-documented feature :)
> >
> > it's documented in ch9 of the eagle book :)
>
> If it is, consider it documented in the next version of the Guide :)
I'm looking at page 456 right now, and from my newbie perspective, I
conclude it's mostly documented. :-) "If called in a scalar context w/
no arguments, dir_config() returns a hash ref tied to the Apache::Table
class." I then had to look at the Apache::Table class methods to figure
out how
> my @values = $r->dir_config->get('Key');
> and
> my %hash = $r->dir_config->get('Key');
worked in the first place. I doubt I would have put 2 and 2 together on
my own to come up with Doug's snippet. Perhaps I need to become more
familiar with the different APIs? I mention this just another new users
perspective. I guess this is one of those "we'll leave it up to the
reader to prove this theorem" situations? :-)
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
RE: [excitement :)] mod_perl rocks!
On Mon, 8 May 2000, Mark D Wolinski wrote: > I don't mean to rain on the parade, but... > > The more important number would be to look at the number of unique IPs, > which has only moderately grown. I installed mod_perl this weekend on my > main server to start testing it, etc. Netcraft, of course, reports that > I've got mod_perl, which may be reflected in the next updating of the > mod_perl chart. > > But, since the number of unqiue IP's hasn't grown as much as the number of > unique hosts, the chart just appears to say that some virtual host providers > installed mod_perl on their servers. I think this is a bigger deal than perhaps you're making out... It doesn't matter to me how many single IP addresses get mod_perl - if the number of virtual hosts is going up with mod_perl on, that translates directly into more people having access to mod_perl, and more "servers" with mod_perl on. Whereas more IP addresses really doesn't tell you much - especially if an ISP hosts 200 hosts or more on 1 box! -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
RE: [excitement :)] mod_perl rocks!
I don't mean to rain on the parade, but... The more important number would be to look at the number of unique IPs, which has only moderately grown. I installed mod_perl this weekend on my main server to start testing it, etc. Netcraft, of course, reports that I've got mod_perl, which may be reflected in the next updating of the mod_perl chart. But, since the number of unqiue IP's hasn't grown as much as the number of unique hosts, the chart just appears to say that some virtual host providers installed mod_perl on their servers. If that is so, then wouldn't all of the virtual hosts on that system report mod_perl, despite the fact that they might not be? Mark W > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Richard Dice > Sent: Monday, May 08, 2000 8:35 AM > To: Tim Sweetman > Cc: mod_perl list > Subject: Re: [excitement :)] mod_perl rocks! > > > Tim: > > Mod_perl isn't going to grow if Apache doesn't grow if the Web doesn't > grow if the Internet doesn't grow... at least, not until technologies > start eating into each other's pre-installed base. And that's a hard > thing to do. > > However, what Stas was pointing out was the explosive growth of > mod_perl -- > it's all out of proportion to the growth of the rest of them. > > Cheers, > Richard > > > > Take a look at the updated graph of the mod_perl growth: > > > > > > http://perl.apache.org/netcraft/ > > > > > > Pay attention to the ramp! > > > > > > BTW, Apache holds 61.53% of the server market share!!! > > > http://www.netcraft.co.uk/survey/ > > > > > > Does this have as much to do with the growth of the 'net as with the > > popularity of mod_perl> > > > > -- > -- > Richard Dice * Personal 514 816 9568 * Fax 514 816 9569 > ShadNet Creator * http://shadnet.shad.ca/ * [EMAIL PROTECTED] > Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/ > "squeeze the world 'til it's small enough to join us heel to toe" > - jesus jones
Re: [excitement :)] mod_perl rocks!
Suddenly, Tim Sweetman uttered:
> Stas Bekman wrote:
> >
> > Take a look at the updated graph of the mod_perl growth:
> >
> > http://perl.apache.org/netcraft/
> >
> > Pay attention to the ramp!
> >
> > BTW, Apache holds 61.53% of the server market share!!!
> > http://www.netcraft.co.uk/survey/
>
>
> Does this have as much to do with the growth of the 'net as with the
> popularity of mod_perl>
>
Very possible... IMO, it would be more useful with a graph showing the
percentage of all domains running apache that also are running mod_perl...
(and perhaps % of all domains running mod_perl?)
- Salve J. Nilsen
--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}"; __END__ is near! :)
Re: [excitement :)] mod_perl rocks!
Tim: Mod_perl isn't going to grow if Apache doesn't grow if the Web doesn't grow if the Internet doesn't grow... at least, not until technologies start eating into each other's pre-installed base. And that's a hard thing to do. However, what Stas was pointing out was the explosive growth of mod_perl -- it's all out of proportion to the growth of the rest of them. Cheers, Richard > > Take a look at the updated graph of the mod_perl growth: > > > > http://perl.apache.org/netcraft/ > > > > Pay attention to the ramp! > > > > BTW, Apache holds 61.53% of the server market share!!! > > http://www.netcraft.co.uk/survey/ > > > Does this have as much to do with the growth of the 'net as with the > popularity of mod_perl> > Richard Dice * Personal 514 816 9568 * Fax 514 816 9569 ShadNet Creator * http://shadnet.shad.ca/ * [EMAIL PROTECTED] Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/ "squeeze the world 'til it's small enough to join us heel to toe" - jesus jones
[OT] Re: [excitement :)] mod_perl rocks!
On Mon, 8 May 2000, G.W. Haywood wrote: > Hi Stas, > > On Mon, 8 May 2000, Stas Bekman wrote: > > > Take a look at the updated graph of the mod_perl growth: > > > > http://perl.apache.org/netcraft/ > > > > Pay attention to the ramp! > > > > BTW, Apache holds 61.53% of the server market share!!! > > So it's gone down a bit then?? See the graph at http://www.netcraft.co.uk/survey/ It's up. __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: modperl rocks
> Does this have as much to do with the growth of the 'net as with the > popularity of mod_perl> > Unless the growth of websites has doubled in 2000, no. Which is well..., unlikely. The number of sites that netcraft surveyed might have doubled in the last 4 months though..., that is something interesting to check up on. I think it's mostly that us mod_perl programmers have been oftly busy :-). Lord knows I have. Shane.
Re: [excitement :)] mod_perl rocks!
Hi Stas, On Mon, 8 May 2000, Stas Bekman wrote: > Take a look at the updated graph of the mod_perl growth: > > http://perl.apache.org/netcraft/ > > Pay attention to the ramp! > > BTW, Apache holds 61.53% of the server market share!!! So it's gone down a bit then?? 73, Ged. > http://www.netcraft.co.uk/survey/
Getting ENV in PerlTransHandler
Hi, How do I get ENV variables values in my PerlTransHandler. I want to know the HTTP_USER_AGENT in my PerlTransHandler. Please suggest me. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: [excitement :)] mod_perl rocks!
Stas Bekman wrote: > > Take a look at the updated graph of the mod_perl growth: > > http://perl.apache.org/netcraft/ > > Pay attention to the ramp! > > BTW, Apache holds 61.53% of the server market share!!! > http://www.netcraft.co.uk/survey/ Does this have as much to do with the growth of the 'net as with the popularity of mod_perl> -- Tim Sweetman A L Digital
[excitement :)] mod_perl rocks!
Take a look at the updated graph of the mod_perl growth: http://perl.apache.org/netcraft/ Pay attention to the ramp! BTW, Apache holds 61.53% of the server market share!!! http://www.netcraft.co.uk/survey/ __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: Newbie Question -
> -Original Message- > From: Doug MacEachern [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 05, 2000 6:22 PM > To: Geoffrey Young > Cc: 'Pierre J. Nicolas'; [EMAIL PROTECTED] > Subject: RE: Newbie Question - > > > > > mod_perl overrides the perl print() function - print()ing to STDOUT > > explititly will not work. > > just use print() if you can... > > sure it will, > > print STDOUT "hi"; > > and > > print "hi"; > > are the same thing, provided STDOUT is the currently selected output > filehandle, which it is by default. ack, I swore I tried this just last week and it didn't work - clearly is does. Sorry for the misinformation... --Geoff >
Re: Most nonesense I've ever read about mod_perl
> >For GUI programming, I think a "beautiful" object design is > >exceptionally important. But once you leave the GUI space, you've > >left the area where "beautiful" object designs add much benefit. Most > >of us programmers are relagated to things that are less beautiful, but > >rather functional. Functional things require good algorithms. Things > >with bad algorithms just become messy, and non functional after a > >period of time. (Let me note that I am not speaking of > >"function/procedural" languages, just the task it must accomplish: > >pretty vs. do the job) > > Now come on. That's a bit heavy. OO is just as useful server-side as > client-side. Agreed Gunther, I tried to soften that with my later comment because I realized it was overboard/not exactly true. I mean to say OO as a replacement for decent algorithm training makes some sense at the GUI level (Yikes did I just open myself for flames). What I really mean is that the only place that *I* see where OO training is more important than algorithm training is in GUI design. I'm arguing against the precendents as I see them in our school system. I would say that we need more focus on algorithms starting with procedural langauges, and then moving to design patterns with OO. Not... Oh, here is some design patterns, what algorithms? Nah, forget about that, that's only for programming in c, who does that anymore? (Uhm, most everyone, but that's the position that seemed quite apparent to me at the University level YMMV) > I think I've benefited just as much from server side OO as client-side. > There are also a load of design patterns which are dedicated to processing > data over networks or distributed systems. eg see CORBA Design Patterns by > Malveau and Mowbray. While the title of the book says CORBA, at least 3 of > the design patterns in there are applicable to mod_perl, EJB, Servlets, and > DCOM communications. We really all have..., the Apache request object comes to mind in mod_perl. > This one isn't detailed in that book, but even Session is a "documented" > design pattern with an OO interface and that's certainly server-side. > > Now, while you can accomplish making an object interface with functional > programming, (eg a web server could be thought of as an object, with an > HTTP get method and post method), the plain fact is that it is a lot > simpler to maintain if your language supports your interface. This is the sort of approach that Java takes. Personally... I find it to be cleaner. However, I also find it unbearable. You see personally I prefer to program the main application in c, with c++ classes that interact for important functions, GUI, Database access, Storage, etc. You develope things that should be "objects" with clearly well laid out algorithms for there various functions. However for program logic I've always found object languages to be..., well, sort of silly. So I use a c program to wrap all these things up. Where perl comes into play is when I want something done fast. I use the same sort of approach though. The "application" are sets of Perl objects/modules. The program logic are just simple sets of scripts that interact with these Modules/objects. Set the properties on the objects and it gives answers that compute into the program logic flow. Generally seperation between logical flow of an application is best done in a procedural language in my experience. You define a series of objects which can be re-used a billion times in your application flow. So say for instance your building an accounting package. You have all sorts of reports, each of them are represented by a "class hierarchy", then you use a quick and dirty perl script to create the right type of object/module, set it's properties, and display it. This way you could include reports in any other part of your program set. Oh well..., this is just the way I like to do things. > >My point is simple. Object orientation is not a replacement for good > >algorithms. It's supplemental to good algorithms, and indeed > >sometimes crufty/beautiful Object interfaces can get in the way of good > >algorithms. (OO interfaces sometimes make Nazi designers out of the > >best of us..., we allow our sense of design to get in the way of our > >sense of algorithms.) > > That may be true. But it doesn't obviate the usefulness of OO on the server. Clearly you are correct. I should have been more clear. > But by the same token, you may as well say forget procedural programming > because it gets in the way of optimizations involving globals stuck in > machine code registers. That is a good point, especially with the poor architecture most of us are working on (x86)..., now if we had more alpha's lying around... :) > > There are a couple things about server side programming that I would agree > with: > > Algorithms tend not to change so often because they are contract. GUIs > change ALL the time. Therefore, maintenance is n
Re: Most nonesense I've ever read about mod_perl
At 01:44 AM 5/8/00 +, [EMAIL PROTECTED] wrote: >On Mon, May 08, 2000 at 08:55:56AM +0100, Matt Sergeant wrote: > > On Sun, 7 May 2000, Jeff Stuart wrote: > > > > > [...rest of message deleted...] > > > > Every language has it use, the truly knowledgeable understand when to > > > > use each language:) > > > > > > > Sam > > > Amen to that!!! I think that this point and the point about writing GOOD > > > algorithms are VERY important ones and I think that it's important > that this > > > be taught! I'm not sure if it's being taught now in school but in my day > > > (GOD I sound old :)) (1987-1991) it wasn't. > > > > I hear this very much depends what Uni you go to. I'm always surprised to > > hear that people _don't_ just learn pure algorithms and techniques at Uni > > - that's certainly all that appears to be taught here in the UK > > (learning languages has to be done on your own time generally, even ones > > that are a core part of your course). > >I think it depends a lot on the school you go to and the professors >you get. I was a Math/Econ major with a tack on of PIC, program in >computing at UCLA. For the most part the teachers were idiots, they >didn't even know what open source was much less get into it in class. >They didn't teach algorithms, they thought it was good enough to teach >the "end all be all" of object orientation. In my experience, good >algorithm training that *used* to be present has been replaced with >object orientation as a "replacement" for good algorithms. This is >basically retarded. (I don't mean to be obtuse, but those are the >facts as I see them) (It's been a few years, maybe they teach OSS in >class now) > >For GUI programming, I think a "beautiful" object design is >exceptionally important. But once you leave the GUI space, you've >left the area where "beautiful" object designs add much benefit. Most >of us programmers are relagated to things that are less beautiful, but >rather functional. Functional things require good algorithms. Things >with bad algorithms just become messy, and non functional after a >period of time. (Let me note that I am not speaking of >"function/procedural" languages, just the task it must accomplish: >pretty vs. do the job) Now come on. That's a bit heavy. OO is just as useful server-side as client-side. I think I've benefited just as much from server side OO as client-side. There are also a load of design patterns which are dedicated to processing data over networks or distributed systems. eg see CORBA Design Patterns by Malveau and Mowbray. While the title of the book says CORBA, at least 3 of the design patterns in there are applicable to mod_perl, EJB, Servlets, and DCOM communications. This one isn't detailed in that book, but even Session is a "documented" design pattern with an OO interface and that's certainly server-side. Now, while you can accomplish making an object interface with functional programming, (eg a web server could be thought of as an object, with an HTTP get method and post method), the plain fact is that it is a lot simpler to maintain if your language supports your interface. >My point is simple. Object orientation is not a replacement for good >algorithms. It's supplemental to good algorithms, and indeed >sometimes crufty/beautiful Object interfaces can get in the way of good >algorithms. (OO interfaces sometimes make Nazi designers out of the >best of us..., we allow our sense of design to get in the way of our >sense of algorithms.) That may be true. But it doesn't obviate the usefulness of OO on the server. But by the same token, you may as well say forget procedural programming because it gets in the way of optimizations involving globals stuck in machine code registers. There are a couple things about server side programming that I would agree with: Algorithms tend not to change so often because they are contract. GUIs change ALL the time. Therefore, maintenance is not so much of a problem on servers as it is on GUIs which means that the maintenance benefits that OO affords is less. But it isn't non existent and in fact OO helps quite a bit even on the server side. Arguably, the more complex a server-side system becomes with more developers, the more the server side system needs to be clean and strongly interfaced... and OO helps support that quite a bit because an OO system contains syntactic glue that supports strong interfacing. Later, Gunther >Allright, well, I'm done ranting about languages, sorry to bring you >along for the trip :-). >Thanks, >Shane. > >(Let me make a quick note: I had two good professors. Dr. Kirby, and >one other fellow I can't remember the name now..., hey! it's been a >while! :) __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Most nonesense I've ever read about mod_perl
On Mon, May 08, 2000 at 08:55:56AM +0100, Matt Sergeant wrote: > On Sun, 7 May 2000, Jeff Stuart wrote: > > > [...rest of message deleted...] > > > Every language has it use, the truly knowledgeable understand when to > > > use each language:) > > > > > Sam > > Amen to that!!! I think that this point and the point about writing GOOD > > algorithms are VERY important ones and I think that it's important that this > > be taught! I'm not sure if it's being taught now in school but in my day > > (GOD I sound old :)) (1987-1991) it wasn't. > > I hear this very much depends what Uni you go to. I'm always surprised to > hear that people _don't_ just learn pure algorithms and techniques at Uni > - that's certainly all that appears to be taught here in the UK > (learning languages has to be done on your own time generally, even ones > that are a core part of your course). I think it depends a lot on the school you go to and the professors you get. I was a Math/Econ major with a tack on of PIC, program in computing at UCLA. For the most part the teachers were idiots, they didn't even know what open source was much less get into it in class. They didn't teach algorithms, they thought it was good enough to teach the "end all be all" of object orientation. In my experience, good algorithm training that *used* to be present has been replaced with object orientation as a "replacement" for good algorithms. This is basically retarded. (I don't mean to be obtuse, but those are the facts as I see them) (It's been a few years, maybe they teach OSS in class now) For GUI programming, I think a "beautiful" object design is exceptionally important. But once you leave the GUI space, you've left the area where "beautiful" object designs add much benefit. Most of us programmers are relagated to things that are less beautiful, but rather functional. Functional things require good algorithms. Things with bad algorithms just become messy, and non functional after a period of time. (Let me note that I am not speaking of "function/procedural" languages, just the task it must accomplish: pretty vs. do the job) My point is simple. Object orientation is not a replacement for good algorithms. It's supplemental to good algorithms, and indeed sometimes crufty/beautiful Object interfaces can get in the way of good algorithms. (OO interfaces sometimes make Nazi designers out of the best of us..., we allow our sense of design to get in the way of our sense of algorithms.) Allright, well, I'm done ranting about languages, sorry to bring you along for the trip :-). Thanks, Shane. (Let me make a quick note: I had two good professors. Dr. Kirby, and one other fellow I can't remember the name now..., hey! it's been a while! :)
RE: Most nonesense I've ever read about mod_perl
At 08:55 AM 5/8/00 +0100, Matt Sergeant wrote: >On Sun, 7 May 2000, Jeff Stuart wrote: > > > [...rest of message deleted...] > > > Every language has it use, the truly knowledgeable understand when to > > > use each language:) > > > > > Sam > > Amen to that!!! I think that this point and the point about writing GOOD > > algorithms are VERY important ones and I think that it's important that > this > > be taught! I'm not sure if it's being taught now in school but in my day > > (GOD I sound old :)) (1987-1991) it wasn't. > >I hear this very much depends what Uni you go to. I'm always surprised to >hear that people _don't_ just learn pure algorithms and techniques at Uni >- that's certainly all that appears to be taught here in the UK >(learning languages has to be done on your own time generally, even ones >that are a core part of your course). Depends on your school. Many are under pressure to produce students that can do work in particular technologies straight out of school. And not just from the businesses, but by students who complain that they need to know Java or how to configure NT servers to get a job. On the worse side, I have seen universities in the USA get huge grants and magically change their entire curriculum to something as daft as Ada just because the grant came from an Ada-proponent. (note: ada is not a bad language just a pretty hard to find anything written in it in the real world language). Hmmm, this is becoming very much like an off-topic slashdot thread. __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
RE: Most nonesense I've ever read about mod_perl
On Sun, 7 May 2000, Jeff Stuart wrote: > [...rest of message deleted...] > > Every language has it use, the truly knowledgeable understand when to > > use each language:) > > > Sam > Amen to that!!! I think that this point and the point about writing GOOD > algorithms are VERY important ones and I think that it's important that this > be taught! I'm not sure if it's being taught now in school but in my day > (GOD I sound old :)) (1987-1991) it wasn't. I hear this very much depends what Uni you go to. I'm always surprised to hear that people _don't_ just learn pure algorithms and techniques at Uni - that's certainly all that appears to be taught here in the UK (learning languages has to be done on your own time generally, even ones that are a core part of your course). -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Problem compiling mod_perl 1.23 on Solaris 2.4
John D Groenveld wrote:
> -Xa is a Sun WorkShop Compiler C 4.2 option,
> -X[a|c|s|t]
> Specifies the degree of conformance to the ANSI C stan-
> dard. Specifies one of the following:
>
> a (ANSI)
>ANSI C plus K&R C compatibility extensions, with
>semantic changes required by ANSI C. Where K&R C
>and ANSI C specify different semantics for the
>same construct, the compiler will issue warnings
>about the conflict and use the ANSI C interpreta-
>tion. This is the default compiler mode.
The machine I was building on was Solaris 2.4 with the Sun Compiler v3.0
in which the cc manpage says "-Xt" ('transition') is the default. I
also have a Solaris 2.6 machine with the Sun Compiler v4.0 which says,
like the snippet above, that "-Xa" is the default.
Steve Hay
Re: OT: Re: Most nonesense I've ever read about mod_perl
On Sun, 7 May 2000, Frank Mayhar wrote: > Perl does have some good constructs for Web work, too. I've been writing > a webstore and some stuff is really convenient that would be inconvenient > in C. On the other hand, there's some stuff that I just wouldn't use Perl > for, like, say, a system daemon, and there's other stuff that I _can't_ use > it for, like in the kernel. Do a web search for perlfs - yes someone really did embed perl into the Linux kernel ;-) -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
