cvs commit: modperl-2.0 Changes
dougm 2002/08/19 13:02:24 Modified:.Changes Log: updates from post-_04 changes Revision ChangesPath 1.34 +7 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- Changes 16 Aug 2002 10:22:39 - 1.33 +++ Changes 19 Aug 2002 20:02:24 - 1.34 -40,6 +40,13 apr_table_t is now an opaque type, use apr_table_elts() to get the array record [Stas Bekman] +add support for redirects with PerlOptions +ParseHeaders + +backport to 2.0.35 + +adjust to filter register api change + +added APR::ThreadMutex module =item 1.99_04 - June 21, 2002
cvs commit: modperl-2.0/src/modules/perl modperl_filter.c
dougm 2002/08/19 13:07:01
Modified:.Changes
src/modules/perl modperl_filter.c
Log:
fix PerlOptions +ParseHeaders to only parse once per-request
Revision ChangesPath
1.35 +2 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- Changes 19 Aug 2002 20:02:24 - 1.34
+++ Changes 19 Aug 2002 20:07:01 - 1.35
-10,6 +10,8
=item 1.99_05-dev
+fix PerlOptions +ParseHeaders to only parse once per-request
+
add external redirects Registry tests [Stas Bekman]
get rid of the compat layer in ModPerl-Registry [Stas Bekman]
1.38 +2 -0 modperl-2.0/src/modules/perl/modperl_filter.c
Index: modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- modperl_filter.c 14 Aug 2002 14:54:47 - 1.37
+++ modperl_filter.c 19 Aug 2002 20:07:01 - 1.38
-14,6 +14,8
const char *bodytext = NULL;
int status = modperl_cgi_header_parse(r, (char *)buf, bodytext);
+wb-header_parse = 0; /* only once per-request */
+
if (status == HTTP_MOVED_TEMPORARILY) {
return APR_SUCCESS; /* XXX: HTTP_MOVED_TEMPORARILY ? */
}
Compile problem
I get an error when I try to compile mod_perl. I have tried to read the manuals, but I do not find anything appropriate. I am using Perl 5.6.1 and httpd-2.0.40. Apache builds and installs without problems. From the httpd-2.0.40 directory this is done using: ./configure --prefix=/usr/local/apache-2.0 --with-mpm=prefork make make install Then I try to build mod_perl. I picked up mod_perl-2.0-current.tar.gz which unpacks as mod_perl-1.99_04. In the mod_perl-1.99.04 directory I try perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 This works fine. No errors or warnings. Then I try make This gives the following output: cd src/modules/perl make -f Makefile.modperl make[1]: Entering directory `/usr/src/redhat/SOURCES/mod_perl-1.99_04/src/modules/perl' gcc -I/usr/src/redhat/SOURCES/mod_perl-1.99_04/src/modules/perl -I/usr/src/redhat/SOURCES/mod_perl-1.99_04/xs -I/usr/local/apache2/include -fno-strict-aliasing -I/usr/local/include -I/usr/lib/perl5/5.6.1/i386-linux/CORE -DMOD_PERL -O2 -march=i386 -mcpu=i686 -fPIC \ -c mod_perl.c mv mod_perl.o mod_perl.lo mod_perl.c: In function `modperl_register_hooks': mod_perl.c:511: warning: passing arg 3 of `ap_register_output_filter' makes pointer from integer without a cast mod_perl.c:511: too few arguments to function `ap_register_output_filter' mod_perl.c:515: warning: passing arg 3 of `ap_register_input_filter' makes pointer from integer without a cast mod_perl.c:515: too few arguments to function `ap_register_input_filter' mod_perl.c:519: warning: passing arg 3 of `ap_register_output_filter' makes pointer from integer without a cast mod_perl.c:519: too few arguments to function `ap_register_output_filter' mod_perl.c:523: warning: passing arg 3 of `ap_register_input_filter' makes pointer from integer without a cast mod_perl.c:523: too few arguments to function `ap_register_input_filter' make[1]: *** [mod_perl.lo] Error 1 make[1]: Leaving directory `/usr/src/redhat/SOURCES/mod_perl-1.99_04/src/modules/perl' make: *** [modperl_lib] Error 2 What am I doing wrong? Best regards, Bjarte Kileng
Re: DBI-connect_cached not playing with Apache::DBI
On Fri, Aug 16, 2002 at 04:07:52PM -0700, Michael G Schwern wrote: On Tue, Aug 13, 2002 at 10:22:35PM +0100, Tim Bunce wrote: But how about a new method: DBI-connect_method(connect); DBI-connect_method(Apache::DBI::connect); # effectively what use Apache::DBI; does now DBI-connect_method(connect_cached); Useful, but doesn't solve the problem. Actually it would. I wasn't very clear. The application would do DBI-connect_method(connect_cached); and $dbh = DBI-connect(...); I'm confused. How, or maybe it's better to ask why, would this be different than just: $dbh = DBI-connect_cached(...); Why would useing connect_method() make it automagical but connect_cached() not? Good question. I'm kind'a making this up as I go along and I can't now remember where I thought the point of leverage/indirection was. I'm coming round to the view that Apache::DBI should simply override the behaviour of DBI-connect_cached in addition to DBI-connect... Which is where you came in :) Patches welcome. [I've finally fixed the CC line to have the correct address for [EMAIL PROTECTED] and would appreciate comments from anyone who can think of a good reason not to have Apache::DBI override connect_cached in addition to connect.] Tim.
Weird: Perl/Perl [mp2]
Greetings. This happens on win32. If the following is inserted in httpd.conf: Perl /Perl I get, reasonbly enough: Syntax error on line 961 of D:/Apache2/conf/httpd.conf: Perl sections not yet implemented in modperl-2.0 Tough, but fair. But why should the following: IfDefine fubar Perl /Perl /IfDefine give me the totally unreasonable: Syntax error on line 960 of D:/think4/Apache2/conf/httpd.conf: Expected /Perl but saw /Perl Obviously minor, but gave me about 15 mins. of head scratching... Cheers, alf
Re: Mod_perl Application Development
On Sun, Aug 18, 2002 at 12:31:03AM +0100, Jonathan Lonsdale wrote: I'm curious to know how people approach application development with mod_perl in situations where there could be dozens of distinct screens/interfaces. I'm currently using the HTML::Template system. When using HTML::Template, I've found its query() method useful to tell the controller what code to call to pass data back to the template: http://perlmonks.org/index.pl?node_id=150608 Tom
Re: Compile problem
On 19 Aug 2002, Bjarte Kileng wrote: I get an error when I try to compile mod_perl. I have tried to read the manuals, but I do not find anything appropriate. I am using Perl 5.6.1 and httpd-2.0.40. Apache builds and installs without problems. From the httpd-2.0.40 directory this is done using: ./configure --prefix=/usr/local/apache-2.0 --with-mpm=prefork make make install Then I try to build mod_perl. I picked up mod_perl-2.0-current.tar.gz which unpacks as mod_perl-1.99_04. In the mod_perl-1.99.04 directory I try perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 This works fine. No errors or warnings. Then I try make This gives the following output: [ .. ] -c mod_perl.c mv mod_perl.o mod_perl.lo mod_perl.c:511: warning: passing arg 3 of `ap_register_output_filter' makes pointer from integer without a cast mod_perl.c:511: too few arguments to function `ap_register_output_filter' [ .. ] With apache-2.0.40, you should use the cvs version of mod_perl-2. -- best regards, randy kobes
Re: HTML::Template
On Mon, 19 Aug 2002, Pierre Vaudrey wrote: with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF For some reason vingette.gif is being interpreted as a Perl script instead of an image. This is probably a case of a misconfigured web server, although I don't know enough about your setup to be sure. What happens if you try to load this image separate from HTML::Template, just by typing the URL into your browser? -sam
Re: Mod_perl Application Development
Jonathan Lonsdale wrote: 2. Distinct content handlers each with their own Location directive. Could be a pain to maintain the server config. You would typically have a single handler that covers one application with many screens, so instead of having an entry there for every template you would have a just a small number of entries for applications like a shopping cart or a message board. The applications then manage which template to send out on each request using their own internal logic. Things like CGI::Application and Apache::PageKit are a formalization of this approach. People often seem to get bent out of shape about putting a few Location directives in httpd.conf, but I find it simple to manage and like doing this the standard way. Having Location directives lets you use all of the normal Apache config options for access control, customized logging, etc. without inventing your own config system. There are exceptional situations (a requirement to add new handlers without a restart, for example), but most people will be just fine doing it the old-fashioned way. - Perrin
Apache::Session - What goes in session?
I'm using mod_perl and Apache::Session on an app that is similar to MyYahoo. I found a few bits of info from a previous thread, but I'm curious as to what type of information should go in the session and what should come from the database. Currently I'm putting very little in the session, but what I am putting in the session is more global in nature...greeting, current page number, current page name...data that doesn't change very often. I'm pulling a lot of info from the database and I wonder if my design is sound. Most of the info being pulled from the database is features for the page. Now I need to add global modules to the page which will show user info like which pages they have created and which features are being emailed to the user. These modules will display on every page unless the user turns them off. It seems that since this info wouldn't change very often that I should put the data in the session... Anyone have any general tips on session design? Thanks. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
AutoLoader bypass?
It wasn't until recently that I realized that the functionality of AutoLoader might actually be counter-productive for mod_perl, at least in a prefork MPM. Because routines are loaded when they are requested, they may be loaded in child processes, causing duplication in memory because they are not shared. They would be shared if they would be loaded in the initialization phase before the child processes are forked. But in that phase you wouldn't call all of those routines that you might need in the child processes. I was therefore thinking about the development of a module that would just go through %INC and check each of the modules for auto/*.al files and do() all of them (possibly limited by a hash keyed to module names with subroutine lists). And then possibly disable AutoLoader altogether, so no memory would inadvertently be lost by routines being loaded by child processes. Does such a beast exist already? If not, would such a module make sense? What would be a good name for it? Liz
Re: AutoLoader bypass?
On 2002.08.19 13:53 Elizabeth Mattijsen wrote: Because routines are loaded when they are requested, they may be loaded in child processes, causing duplication in memory because they are not shared. They would be shared if they would be loaded in the initialization phase before the child processes are forked. But in that phase you wouldn't call all of those routines that you might need in the child processes. I don't know of a module or standardized way of doing this, but the CGI module offers this to the user in the form of a compile directive in the imports list. It tells the module proper to pre-compile the specified list of routines, and (as I understand it) the functionality stemmed from the kind of situation you describe, where application developers wanted to ensure that load-on-demand functions be pre-loaded before forking. The problem I would anticipate would be in having a portable way of locating the code to load without having it executed. You could pull some functionality out of AutoLoader, but then you have code duplication. Or, an idea that just hit me, you could provide a call in the AutoLoader module that does the job for you. It would have access to all the logic already in the module, and module-writers could use it conditionally a la: AutoLoader::preload(__PACKAGE__, @routines) if $running_under_modperl; Where the @routines list is optional, and defaults to every *.al file found for __PACKAGE__. Randy -- --- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 650 930-9097 | -- Sir Winston Churchill
Re: AutoLoader bypass?
At 02:05 PM 8/19/02 -0700, Randy J. Ray wrote:
Because routines are loaded when they are requested, they may be loaded in
child processes, causing duplication in memory because they are not shared.
They would be shared if they would be loaded in the initialization phase
before the child processes are forked. But in that phase you wouldn't call
all of those routines that you might need in the child processes.
The problem I would anticipate would be in having a portable way of locating the code
to load without having it executed. You could pull some functionality out of
AutoLoader, but then you have code duplication.
Indeed. Most of the necessary code is in AutoLoader::import and AutoLoader::AUTOLOAD
already.
Or, an idea that just hit me, you could provide a call in the AutoLoader module that
does the job for you. It would have access to all the logic already in the module,
and module-writers could use it conditionally a la:
AutoLoader::preload(__PACKAGE__, routines)
if $running_under_modperl;
Where the routines list is optional, and defaults to every *.al file found for
__PACKAGE__.
I was more thinking along:
use AutoLoader; # current behaviour
use AutoLoader 'AUTOLOAD'; # import AUTOLOAD
use AutoLoader 'preload'; # preload anything you can find in %INC
use AutoLoader preload = { module = '' }; # all from specific module
use AutoLoader preload = { module = [qw(suba subb)] }; # only specific
Would that make sense?
Liz
Re: AutoLoader bypass?
On 2002.08.19 14:19 Elizabeth Mattijsen wrote:
use AutoLoader 'preload'; # preload anything you can find in %INC
use AutoLoader preload = { module = '' }; # all from specific module
use AutoLoader preload = { module = [qw(suba subb)] }; # only specific
Would that make sense?
Problem with that approach is that it doesn't offer any control over whether
you are pre-loading or not. If you are going to pre-load a certain sub-set of
routines all the time, just put them above the __END__ token and don't burden
AutoLoader with new functionality at all.
What I was suggesting was a way that I, as the writer of (picking one of my
own modules as an example) RPC::XML::Server can incorporate something in the
compile-time logic so that Apache::RPC::Server contains:
use RPC::XML::Server 'compile';
And RPC::XML::Server can have:
sub import {
AutoLoader::preload(__PACKAGE__, @list_o_routines)
if (lc $_[1] eq 'compile');
}
(Admittedly a simplistic example, but I hope it gets the point across)
This way, I only pre-load routines in the cases where I need it done. Your
suggestion is good for modules that are only ever used under mod_perl, but
modules may be designed to work in other environments. Oh, you could manage
to get the same affect as my idea using a BEGIN block and conditional calls
of use AutoLoader, but the above seems to me to be much cleaner.
Randy
--
---
Randy J. Ray | Men occasionally stumble over the truth, but most of them
[EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened.
+1 650 930-9097 | -- Sir Winston Churchill
RE: Apache::Session - What goes in session?
Hello md -- I'm using mod_perl and Apache::Session on an app that is similar to MyYahoo. I found a few bits of info from a previous thread, but I'm curious as to what type of information should go in the session and what should come from the database. One thing to watch out for is the trap of using session data as a dumping ground for global variables. Since you are asking what belongs in a session, it seems you are already thinking along those lines. I have found that many people who are fond of sessions often use them to store data which I would be personally inclined to store in hidden form data, in a simple cookie, or retrieve from a database when needed. In my systems I usually only store a single session ID in a cookie -- a key which references a database row. This allows me to have as much data as I like but keep it all in the database. There is one case where it might make sense to put data into a session of some sort -- to cache information which is very time-consuming to retrieve. Minimizing time-consuming database operations is an important thing to think about in large systems, and a place where session data might come in handy. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: AutoLoader bypass?
At 02:37 PM 8/19/02 -0700, Randy J. Ray wrote:
use AutoLoader 'preload'; # preload anything you can find in %INC
use AutoLoader preload = { module = '' }; # all from specific module
use AutoLoader preload = { module = [qw(suba subb)] }; # only specific
Would that make sense?
Problem with that approach is that it doesn't offer any control over whether
you are pre-loading or not. If you are going to pre-load a certain sub-set of
routines all the time, just put them above the __END__ token and don't burden
AutoLoader with new functionality at all.
Well, my Cuse AutoLoader would be _outside_ any of the loaded modules in the
mod_perl startup.pl script after all the modules necessary for proper execution of
_your_ mod_perl environment, are loaded.
What I was suggesting was a way that I, as the writer of (picking one of my
own modules as an example) RPC::XML::Server can incorporate something in the
compile-time logic so that Apache::RPC::Server contains:
use RPC::XML::Server 'compile';
And RPC::XML::Server can have:
sub import {
AutoLoader::preload(__PACKAGE__, list_o_routines)
if (lc $_[1] eq 'compile');
}
(Admittedly a simplistic example, but I hope it gets the point across)
That also makes sense, but wasn't my original idea.
I'd rather make this a class method, so:
AutoLoader-preload( list_o_routines );
and have the module derive the module name from caller(). That would at least
simplify the call and it would reduce the risk of abuse.
This way, I only pre-load routines in the cases where I need it done. Your
suggestion is good for modules that are only ever used under mod_perl, but
modules may be designed to work in other environments. Oh, you could manage
to get the same affect as my idea using a BEGIN block and conditional calls
of use AutoLoader, but the above seems to me to be much cleaner.
I'm more interested in the modules that either work in a mod_perl environment and a
normal Perl environment. If a module is supposed to be used in mod_perl, it just
shouldn't use AutoLoader.
Liz
[DIGEST] mod_perl digest 2002/08/12
-- mod_perl digest August 12, 2002 - August 18, 2002 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o mod_perlers wanted o links mod_perl status o mod_perl - stable: 1.27 (released June 1, 2002) [1] - development: 1.27_01-dev [2] o Apache - stable: 1.3.26 (released June 18, 2002) [3] - development: 1.3.27-dev [4] o mod_perl 2.0 - beta: 1.99_04 (released June 21, 2002) [5] - development: (from cvs) [6] o Apache 2.0 - stable: 2.0.40 (released August 9, 2002) [7] o Perl - stable: 5.8.0 (released July 18, 2001) [8] - development: none [9] module announcements o OpenInteract 1.41 - extensible web application server [10] o StateMachine::Gestinanna 0.05 - data-driven state machine [11] module rfcs o Graphics::ColorPicker [12] mod_perlers wanted o Senior mod_perl programming in Oslo, Norway [13] links o The Apache/Perl Integration Project [14] o mod_perl documentation [15] o Apache modules on CPAN [16] o _Writing Apache Modules with Perl and C_ homepage [17] o mod_perl news and advocacy [18] o mod_perl list archives - modperl@ [19] - dev@ [20] - docs-dev@ [21] - advocacy@ [22] happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://cvs.apache.org/snapshots/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_04.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/README.html [10] http://mathforum.org/epigone/modperl/grerlkreudrun [11] http://mathforum.org/epigone/modperl/swimpdwendpoa [12] http://mathforum.org/epigone/modperl/serdstreesmam [13] http://mathforum.org/epigone/modperl/dwoyspenhar [14] http://perl.apache.org/ [15] http://perl.apache.org/docs/ [16] http://www.cpan.org/modules/by-module/Apache/ [17] http://www.modperl.com/ [18] http://www.take23.org/ [19] http://perl.apache.org/maillist/modperl.html#Searchable_Archives [20] http://perl.apache.org/maillist/dev.html#Searchable_Archives [21] http://perl.apache.org/maillist/docs-dev.html#Searchable_Archives [22] http://perl.apache.org/maillist/advocacy.html#Searchable_Archives
Re: Apache::Session - What goes in session?
md wrote: Currently I'm putting very little in the session Good. You should put in as little as possible. what I am putting in the session is more global in nature...greeting, current page number, current page name... That doesn't sound very global to me. What happens when users open multiple browser windows on your site? Doesn't it screw up the current page data? I'm pulling a lot of info from the database and I wonder if my design is sound. Optimizing database fetches or caching data is independent of the session issue. Nothing that is relevant to more than one user should ever go in the session. Now I need to add global modules to the page which will show user info like which pages they have created and which features are being emailed to the user. These modules will display on every page unless the user turns them off. That sounds like a user or subscriptions object to me, not session data. It seems that since this info wouldn't change very often that I should put the data in the session... No, that's caching. Don't use the session for caching, use a cache for it. They're not the same. A session is often stored in a database so that it can be reliable. A cache is usually stored on the file system so it can be fast. Things like the login status of this session, and the user ID that is associated with it go in the session. Status of a particular page has to be passed in query args or hidden fields, to avoid problems with multiple browser windows. Data that applies to multiple users or lasts more than the current browsing session never goes in the session. - Perrin
RE: Apache::Session - What goes in session?
Thanks though. That was succinctly put. Could you go back in time and tell me that a year or two ago? That would be great, thanks again. -Josh :) Things like the login status of this session, and the user ID that is associated with it go in the session. Status of a particular page has to be passed in query args or hidden fields, to avoid problems with multiple browser windows. Data that applies to multiple users or lasts more than the current browsing session never goes in the session. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: md wrote: That doesn't sound very global to me. What happens when users open multiple browser windows on your site? Doesn't it screw up the current page data? I don't think global was the term I should have used. What I mean is data that will be seen on all or most pages by the same user...like Hello Jim, where Jim is pulled from the database when the session is created and passed around in the session after that (and updated in the db and session if user changes their greeting name). Current page name and id are never stored in db, so different browser windows can be on different pages...I'm not sure if that's good or bad. However, changes to the user name will be seen in both browser windows since that's updated both in the session and db. Optimizing database fetches or caching data is independent of the session issue. Nothing that is relevant to more than one user should ever go in the session. Correct. That little info I am putting in the session corresponds directly to a single user. That sounds like a user or subscriptions object to me, not session data. Once again, I shouldn't have used the term global. This is the subscriptions info for a single user...that's why I had thought to put this in the session instead of pulling from the db each page call since the data will rarely change. This info will be displayed on every page the user visits (unless they turn off this module). No, that's caching. Don't use the session for caching, use a cache for it. They're not the same. A session is often stored in a database so that it can be reliable. A cache is usually stored on the file system so it can be fast. The session is stored in a database (Apache::Session::MySQL), and I am using TT caching for the templates, but I'm not sure how to cache the non-session data. I've seen this discussed but I definitely need more info on this. As it stands I see two options: get data from the session or get it from the db...how do I bring caching into play? Things like the login status of this session, and the user ID that is associated with it go in the session. Status of a particular page has to be passed in query args or hidden fields, to avoid problems with multiple browser windows. Data that applies to multiple users or lasts more than the current browsing session never goes in the session. What about something like default page id, which is the page that is considered your home page? This id is stored permanently in the db (lasts more than the current current browsing session) but I keep it in the session since this also rarely changes so I don't want to keep hitting the db to get it. Thanks again... __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
md wrote: I don't think global was the term I should have used. What I mean is data that will be seen on all or most pages by the same user...like Hello Jim Okay, don't put that in the session. It belongs in a cache. The session is for transient state information, that you don't want to keep after the user logs out. Current page name and id are never stored in db, so different browser windows can be on different pages... I thought your session was all stored in MySQL. Why are you putting these in the session exactly? If these things are not relevant to more than one request (page), they don't belong in the session. They should just be in ordinary variables. That sounds like a user or subscriptions object to me, not session data. Once again, I shouldn't have used the term global. This is the subscriptions info for a single user...that's why I had thought to put this in the session instead of pulling from the db each page call since the data will rarely change. You should use a cache for that, rather than the session. This is long-term data that you just want quicker access to. I am using TT caching for the templates, but I'm not sure how to cache the non-session data. Template Toolkit caches the compiled template code, but it doesn't cache your data or the output of the templates. What you should do is grab a module like Cache::Cache or Cache::Mmap and take a look at the examples there. You use it in a way that's very similar to what you're doing with Apache::Session for the things you referred to as global. There are also good examples in the documentation for the Memoize module. There are various reasons to use a cache rather than treating the session like a cache. If you put a lot of data in the session, it will slow down every hit loading and saving that data. In a cache, you can just keep multiple cached items separately and only grab them if you need them for this page. With a cache you can store things that come from the database but are not user-specific, like today's weather. What about something like default page id, which is the page that is considered your home page? This id is stored permanently in the db (lasts more than the current current browsing session) but I keep it in the session since this also rarely changes so I don't want to keep hitting the db to get it. I would have some kind of user object which has a property of default_page_id. The first time the user logs in I would fetch that from the database, and then I would cache it so that I wouldn't need to go back to the database for it on future requests. - Perrin
Re: AutoLoader bypass?
On 2002.08.19 14:47 Elizabeth Mattijsen wrote:
At 02:37 PM 8/19/02 -0700, Randy J. Ray wrote:
use AutoLoader 'preload'; # preload anything you can find in %INC
use AutoLoader preload = { module = '' }; # all from specific module
use AutoLoader preload = { module = [qw(suba subb)] }; # only specific
Would that make sense?
Problem with that approach is that it doesn't offer any control over whether
you are pre-loading or not. If you are going to pre-load a certain sub-set
of
routines all the time, just put them above the __END__ token and don't
burden
AutoLoader with new functionality at all.
Well, my Cuse AutoLoader would be _outside_ any of the loaded modules in
the mod_perl startup.pl script after all the modules necessary for proper
execution of _your_ mod_perl environment, are loaded.
I see... you mean to have a line like this:
use AutoLoader preload = { module = [qw(suba subb)] };
be responsible for both including module (into the caller's namespace) *and*
pre-loading the specified routines? That's different that what I had
interpreted from your first idea. I though that the preload specification
would be when the target module issues its call to use AutoLoader.
From this vantage point, it does make more sense, yes. Especially since
module authors would no be responsible for retro-fitting to their packages. I
would be interested to see if this can be done cleanly, without making
AutoLoader.pm any harder to read than it currently is :-).
(OK, that might be asking a bit much...)
Randy
--
---
Randy J. Ray | Men occasionally stumble over the truth, but most of them
[EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened.
+1 650 930-9097 | -- Sir Winston Churchill
Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting serverfails
modperl Gurus, What do you get from running: nm httpd | grep Apache__Log there should be boot_Apache__Log there. I get the following: [2638] |286064| 216|FUNC |GLOB |0|8 |XS_Apache__Log_alert [3893] |286280| 216|FUNC |GLOB |0|8 |XS_Apache__Log_crit [3960] |287360| 216|FUNC |GLOB |0|8 |XS_Apache__Log_debug [3382] |285848| 216|FUNC |GLOB |0|8 |XS_Apache__Log_emerg [3619] |286496| 216|FUNC |GLOB |0|8 |XS_Apache__Log_error [2981] |287144| 216|FUNC |GLOB |0|8 |XS_Apache__Log_info [2566] |285508| 340|FUNC |GLOB |0|8 |XS_Apache__Log_log [3223] |286928| 216|FUNC |GLOB |0|8 |XS_Apache__Log_notice [2866] |286712| 216|FUNC |GLOB |0|8 |XS_Apache__Log_warn [4347] |287988| 772|FUNC |GLOB |0|8 |boot_Apache__Log And, Lupe wrote: John, please check this: grep boot_Apache__Log apache_1.3.26/src/modules/perl/perlxsi.c EXTERN_C void boot_Apache__Log _((CV* cv)); newXS(Apache::Log::bootstrap, boot_Apache__Log, file); When I run the above grep, I get the following: % grep boot_Apache__Log perlxsi.c EXTERN_C void boot_Apache__Log (pTHXo_ CV* cv); newXS(Apache::Log::bootstrap, boot_Apache__Log, file); So, it appears everything still looks okay. What is the next step? Some sort of truss to determine where this is getting messed up? Should I try modifying the configuration to see if that is the problem? Or, should I try to run it under truss to see where it is dying? I would really like to get my servers upgraded. Could it be some version conflict between all the different perl/apache modules? Please let me know what you think about all this. Thank you very much in advance. JohnM ## John Mendenhall ## [EMAIL PROTECTED] ## Senior Network/Systems Administrator
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: Current page name and id are never stored in db, so different browser windows can be on different pages... I thought your session was all stored in MySQL. Why are you putting these in the session exactly? If these things are not relevant to more than one request (page), they don't belong in the session. They should just be in ordinary variables. You are correct, these items are in the session in the db. I meant that they weren't kept in long term storage in the db after the session ended like the default page id and user name are. The current page id/name is only relevent for an active session. Once a session is started current page is set to whatever the default page id is and will change as the user changes pages. The only reason I did this (as I recall) is that way I can get the page name once. You should use a cache for that, rather than the session. This is long-term data that you just want quicker access to. Yes, that's exactly what I want to do. My main concern is long-term data that I want quicker access to. I can definitely get it all from the db, but that doesn't seem very efficient. Template Toolkit caches the compiled template code, but it doesn't cache your data or the output of the templates. What you should do is grab a module like Cache::Cache or Cache::Mmap and take a look at the examples there. You use it in a way that's very similar to what you're doing with Apache::Session for the things you referred to as global. There are also good examples in the documentation for the Memoize module. Great...exactly the kind of info I was looking for. I'll look at those. We are using a load-balanced system; I shoudl have mentioned that earlier. Won't that be an issue with caching to disk? Is it possible to cache to the db? There are various reasons to use a cache rather than treating the session like a cache. If you put a lot of data in the session, it will slow down every hit loading and saving that data. In a cache, you can just keep multiple cached items separately and only grab them if you need them for this page. With a cache you can store things that come from the database but are not user-specific, like today's weather. Thank you for all the excellent advice and explination(in this and other posts). Most of the info I'll be pulling is *very* user-specific...user name, which features to display on which page, what features the user gets by email, etc. What happens is the user logs in and then the username (greeting), the default page id (the user can create many pages with different features per page) and what features go on the default page are pulled from the database and the default page is displayed, as well as any module info. The modules will consist of a pages module with the names of all the pages the user has created (with links) and a emails module which will display all the features that the user is getting via email. These modules will be displayed on every page. You can see that almost everything is user-specific. Right now I'm storing the page names/ids in a hash ref in the session (the emails module isn't live yet), but I thought that I would change that and only store the module id and pull the names from the db (if the user hasn't turned off the module) with each page call. Thanks again for all the info! __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
PDF documentation
Hello list, Does anyone have a working link to a pdf version (mod_perl 1.27) of the guide? Found one in the archives that no longer works... I tried cvs'ing the data and doing the build deal referenced on perl.apache.org, but I'm missing something as I get an error from DocSet/Util.pm. It's trying to load Template.pm on line 13, but I don't have a Template.pm on my system anywhere. Seems to me this should be right in plain sight, but it's late here. Thank you. Regards, Rich
Re: Apache::Session - What goes in session?
md wrote: We are using a load-balanced system; I shoudl have mentioned that earlier. Won't that be an issue with caching to disk? Is it possible to cache to the db? There are a few ways to deal with this. The simplest is to use the sticky load-balancing feature that many load-balancers have. Failing that, you can store to a network file system like NFS or CIFS, or use a database. (There are also fancier options with things like Spread, but that's getting a little ahead of the game.) You can use MySQL for caching, and it will probably have similar performance to a networked file system. Unfortunately, the Apache::Session code isn't all that easy to use for this, since it assumes you want to generate IDs for the objects you store rather than passing them in. You could adapt the code from it to suit your needs though. The important thing is to leave out all of the mutually exclusive locking it implements, since a cache is all about get the latest as quick as you can and lost updates are not a problem (last save wins is good enough for a cache). The modules will consist of a pages module with the names of all the pages the user has created (with links) and a emails module which will display all the features that the user is getting via email. These modules will be displayed on every page. You can see that almost everything is user-specific. The relationships to the features and pages differ by user, but there might be general information about the features themselves that is stored in the database and is not user-specific. That could be cached separately, to save some trips to the db for each user. Right now I'm storing the page names/ids in a hash ref in the session (the emails module isn't live yet), but I thought that I would change that and only store the module id and pull the names from the db (if the user hasn't turned off the module) with each page call. You can cache the names too if you want to, but keeping them out of the session means that you won't be slowed down by fetching that extra data and de-serializing it with Storable unless the page you're on actually needs it. It's also good to separate things that have to be reliable (like the ID of the current user, since without that you have to send them back to log in again) from things that don't need to be (you could always fetch the list of pages from the db if your cache went down). - Perrin
RE: NTLM module
I am still having problems with the AuthenNTLM module. All works fine for IE and Mozilla browsers but when I use Netscape, I am repeatedly promted for passwords. If I enter my password about 3 to 6 times I will eventually get the full page . If I enter password once, ( and cancel for any further password prompts ) I get only bit of the expected page. If I put a sleep (2) in the perl module before it goes to verify against the SMB server, netscape browser will work albeit somewhat slower. The other aspect I can not understand is that when the perl NTLM module is running, it will often exit from sub's other than the handler sub. ie the handler sub is always called first which calls other sub's but whilst executing these other sub''s , it appears that something seems to cut processing short passes control back to apache - the perl code never gets a chance to return to the handler module exit code with a 'return xx'. I have been observing the perl's progress by looking at entries in the error.log . I have also put in a variety of print STDERR staements at key positions to see where the code is exiting. If for instance I put a sleep command in the perl module, the code will often exit whilst the sleep is taking place - it appears that the NTLM module has run out of its allowed time and it has been cut short. The other conclusion is that multiple threads are running and outputting to the error.log confusing me with the overlapping output. This strange exiting behaviour also appears to occur on all browsers (once that work ok netscape that does not work.) The other error I get is that the username/password is passed ok from the SMB server verification phase, but then in subsequent calls to the SMB server, the username/password fails - this occurs during the one entry of username/password but the SMB server is contacted several times for verification ( I also check the username password in the script before thay are submitted to the SMB server so I know they are correct.) Would this be because of timeout in the SMB to respond. I would also expect the SMB server to only need to referred to once, but the perl module is calling the SMB module 3 times during the one username/password entry. I hope the above make sense. I can my log file if this would help. Regards Adam -Original Message- From: Kaye-Smith Adam Sent: Monday, 19 August 2002 9:15 AM To: 'Gerald Richter'; Peter Bi; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: NTLM module Thanks for your advice Gerald. I have found a compromise buy having the directive of Authtype Basic but the perl code has been changed to run the NTLM check as well as SMB (regardlesss of the config file) and if both authentications fail, the standard mod_auth code will then be run. Thanks once again. Adam The information in this e-mail together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any form of review, disclosure, modification, distribution and/or publication of this e-mail message is prohibited. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
RE: NTLM module
I should add that I am using Apache 1.3, perl 5.6.1 mod_perl 1.26. my httpd.conf file for the perl_mod is as below ( I have add the first 3 lines during the cause of troubleshooting. PerlFreshRestart On PerlWarn On PerlSetEnv MOD_PERL_TRACE d; Directory /var/www/html/ # # This may also be None, All, or any combination of Indexes, # Includes, FollowSymLinks, ExecCGI, or MultiViews. # # Note that MultiViews must be named *explicitly* --- Options All # doesn't give it to you. # Options Indexes FollowSymLinks # # This controls which options the .htaccess files in directories can # override. Can also be All, or any combination of Options, FileInfo, # AuthConfig, and Limit # AllowOverride None PerlAuthenHandler +Apache::AuthenNTLM AuthUserFile /tmp/htpasswd AuthName Warning you are entering a development server!! (and AuthType basic #AuthType ntlm,basic #AuthType ntlm PerlAddVar ntdomain LANDS zeta zeta PerlSetVar ntlmauthoritative off PerlSetVar basicauthoritative off PerlSetVar defaultdomain LANDS PerlSetVar ntlmdebug 1 require valid-user # # Controls who can get stuff from this server. # Order allow,deny Allow from all /Directory Regards Adam -Original Message- From: Kaye-Smith Adam Sent: Tuesday, 20 August 2002 2:46 PM To: 'Gerald Richter'; 'Peter Bi'; '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: RE: NTLM module I am still having problems with the AuthenNTLM module. All works fine for IE and Mozilla browsers but when I use Netscape, I am repeatedly promted for passwords. If I enter my password about 3 to 6 times I will eventually get the full page . If I enter password once, ( and cancel for any further password prompts ) I get only bit of the expected page. If I put a sleep (2) in the perl module before it goes to verify against the SMB server, netscape browser will work albeit somewhat slower. The other aspect I can not understand is that when the perl NTLM module is running, it will often exit from sub's other than the handler sub. ie the handler sub is always called first which calls other sub's but whilst executing these other sub''s , it appears that something seems to cut processing short passes control back to apache - the perl code never gets a chance to return to the handler module exit code with a 'return xx'. I have been observing the perl's progress by looking at entries in the error.log . I have also put in a variety of print STDERR staements at key positions to see where the code is exiting. If for instance I put a sleep command in the perl module, the code will often exit whilst the sleep is taking place - it appears that the NTLM module has run out of its allowed time and it has been cut short. The other conclusion is that multiple threads are running and outputting to the error.log confusing me with the overlapping output. This strange exiting behaviour also appears to occur on all browsers (once that work ok netscape that does not work.) The other error I get is that the username/password is passed ok from the SMB server verification phase, but then in subsequent calls to the SMB server, the username/password fails - this occurs during the one entry of username/password but the SMB server is contacted several times for verification ( I also check the username password in the script before thay are submitted to the SMB server so I know they are correct.) Would this be because of timeout in the SMB to respond. I would also expect the SMB server to only need to referred to once, but the perl module is calling the SMB module 3 times during the one username/password entry. I hope the above make sense. I can my log file if this would help. Regards Adam -Original Message- From: Kaye-Smith Adam Sent: Monday, 19 August 2002 9:15 AM To: 'Gerald Richter'; Peter Bi; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: NTLM module Thanks for your advice Gerald. I have found a compromise buy having the directive of Authtype Basic but the perl code has been changed to run the NTLM check as well as SMB (regardlesss of the config file) and if both authentications fail, the standard mod_auth code will then be run. Thanks once again. Adam The information in this e-mail together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any form of review, disclosure, modification, distribution and/or publication of this e-mail message is prohibited. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
Re: NTLM module
Adam: Netscape does behave somehow differently under the authentication. I used to have similar problem with a Perl authen module using Netscape 6 (Netscape 4.0 and 3.0 are okay, however). It looks like N6 uses more caching, and does not tolerate any departure from the httpd 1.1 definition; so one gets often the same pop-up login page instead of the redirected page. You may try to remove any caching tags and add nocache in the code. Peter - Original Message - From: Kaye-Smith Adam [EMAIL PROTECTED] To: Gerald Richter [EMAIL PROTECTED]; Peter Bi [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 19, 2002 9:46 PM Subject: RE: NTLM module I am still having problems with the AuthenNTLM module. All works fine for IE and Mozilla browsers but when I use Netscape, I am repeatedly promted for passwords. If I enter my password about 3 to 6 times I will eventually get the full page . If I enter password once, ( and cancel for any further password prompts ) I get only bit of the expected page. If I put a sleep (2) in the perl module before it goes to verify against the SMB server, netscape browser will work albeit somewhat slower. The other aspect I can not understand is that when the perl NTLM module is running, it will often exit from sub's other than the handler sub. ie the handler sub is always called first which calls other sub's but whilst executing these other sub''s , it appears that something seems to cut processing short passes control back to apache - the perl code never gets a chance to return to the handler module exit code with a 'return xx'. I have been observing the perl's progress by looking at entries in the error.log . I have also put in a variety of print STDERR staements at key positions to see where the code is exiting. If for instance I put a sleep command in the perl module, the code will often exit whilst the sleep is taking place - it appears that the NTLM module has run out of its allowed time and it has been cut short. The other conclusion is that multiple threads are running and outputting to the error.log confusing me with the overlapping output. This strange exiting behaviour also appears to occur on all browsers (once that work ok netscape that does not work.) The other error I get is that the username/password is passed ok from the SMB server verification phase, but then in subsequent calls to the SMB server, the username/password fails - this occurs during the one entry of username/password but the SMB server is contacted several times for verification ( I also check the username password in the script before thay are submitted to the SMB server so I know they are correct.) Would this be because of timeout in the SMB to respond. I would also expect the SMB server to only need to referred to once, but the perl module is calling the SMB module 3 times during the one username/password entry. I hope the above make sense. I can my log file if this would help. Regards Adam -Original Message- From: Kaye-Smith Adam Sent: Monday, 19 August 2002 9:15 AM To: 'Gerald Richter'; Peter Bi; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: NTLM module Thanks for your advice Gerald. I have found a compromise buy having the directive of Authtype Basic but the perl code has been changed to run the NTLM check as well as SMB (regardlesss of the config file) and if both authentications fail, the standard mod_auth code will then be run. Thanks once again. Adam The information in this e-mail together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any form of review, disclosure, modification, distribution and/or publication of this e-mail message is prohibited. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
