Re: how to take advantage of mod_perl and analize effectiveness ofefforts?
On Fri, 2003-03-07 at 18:21, Charlie Smith wrote: What is being cached by the mod_perl? You should definitely read the mod_perl documentation that another poster pointed you to. However, let me address your core question about what is being cached with mod_perl. Technically, mod_perl doesn't cache any differently from Perl itself. When Perl code gets compiled to bytecode it stays in memory until the Perl interpreter exits. The key difference between mod_perl and Perl CGI is that mod_perl keeps the interpeter alive between requests and thus keeps the compiled bytecode in memory as well. This is what people mean by caching code. Some frameworks that you can use with mod_perl, like Mason or Embperl, cache other things as well. This is explained in their documentation. There are ways of configuring mod_perl to automatically pick up changes in your code. This is all described in the mod_perl documentation. - Perrin
Re: Optimising cache performance
Clinton Gormley wrote: For now it's not a distributed system, and I have been using Cache::FileCache. But that still means freezing and thawing objects - which I'm trying to minimise. Other things (IPC::MM, MLDBM::Sync, Cache::Mmap, BerkeleyDB) are significantly faster than Cache::FileCache. If you have tons of free memory, then go ahead and cache things in memory. My feeling is that the very small amount of time that the fastest of these systems use to freeze and thaw is totally made up for in the huge memory savings which allows you to run more server processes. When you say that Cache::Mmap is only limited by the size of your disk, is that because the file in memory gets written to disk as part of VM? ( I don't see any other mention of files in the docs.) Which presumably means resizing your VM to make space for the cache? That's right, it uses your system's mmap() call. I've never needed to adjust the amount of VM I have because of memory-mapping a file, but I suppose it could happen. This would be a good question for the author of the module, or an expert on your system's mmap() implementation. I see the author of IPC::MM has an e-toys address - was this something you used at e-toys? It was used at one point, although not in the version of the system that I wrote about. He originally wrote it as a wrapper around the mm library, and I asked if he could put in a shared hash just for fun. It turned out be very fast, largely because the sharing and the hash (or btree) is implemented in C. The Perl part is just an interface to it. I know very little about shared memory segments, but is MM used to share small data objects, rather than to keep large caches in shared memory? It's a shared hash. You can put whatever you want into it. Apache uses mm to share data between processes. Ralph Engelschall writes in the MM documentation : The maximum size of a continuous shared memory segment one can allocate depends on the underlaying platform. This cannot be changed, of course. But currently the high-level malloc(3)-style API just uses a single shared memory segment as the underlaying data structure for an MM object which means that the maximum amount of memory an MM object represents also depends on the platform. What implications does this have on the size of the cache that can be created with IPC::MM It varies by platform, but I believe that on Linux it means each individual hash is limited to 64MB. So maybe I spoke too soon about having unlimited storage, but you should be able to have as many hashes as you want. If you're seriously concerned about storage limits like these, you could use one of the other options like MLDBM::Sync or BerkeleyDB which use disk-storage. - Perrin
Re: Optimising cache performance
Clinton Gormley wrote: I'd appreciate some feedback on my logic to optimise my cache (under mod_perl 1) First, I'm assuming this is for a distributed system running on multiple servers. If not, you should just download one of the cache modules from CPAN. They're good. I'm planning a two level cache : 1) Live objects in each mod_perl process 2) Serialised objects in a database I suggest you use either Cache::Mmap or IPC::MM for your local cache. They are both very fast and will save you memory. Also, Cache::Mmap is only limited by the size of your disk, so you don't have to do any purging. You seem to be taking a lot of care to ensure that everything always has the latest version of the data. If you can handle slightly out-of-date data, I would suggest that you simply keep objects in the local cache with a time-to-live (which Cache::Mmap or Cache::FileCache can do for you) and just look at the local version until it expires. You would end up building the objects once per server, but that isn't so bad. If everything really does have to be 100% up-to-date, then what you're doing is reasonable. It would be nice to not do the step that checks for outdated objects before processing the request, but instead do it in a cleanup handler, although that could lead to stale data being used now and then. If you were using a shared cache like Cache::Mmap, you could have a cron job or a separate Perl daemon that simply purges outdated objects every minute or so, and leave that out of your mod_perl code completely. Yet another way to handle a distributed cache is to have each write to the cache send updates to the other caches using something like Spread::Queue. This is a bit more complex, but it means you don't need a second-tier in your cache to share updates. - Perrin
Re: Optimising cache performance
Cory 'G' Watson wrote: I'm not sure if my way would fit in with your objects Clinton, but I have some code in the commit() method of all my objects which, when it is called, removes any cached copies of the object. That's how I stay up to date. Why wouldn't it simply update the version in the cache when you commit? Also, do you have a way of synchronizing changes across multiple machines? - Perrin
Re: [mp2] integration with apache threads
Pavel Hlavnicka wrote: Is there some relation between Perl threads and Apache threads? What I mean: If Apache fires a new thread, what happens in mod_perl? Are perl structures copied from the parent thread interpreter to the new one? ... or is the new perl environment clean? Have you read this? http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support I believe this addresses your questions. For the details of how Perl threads work, read this: http://perldoc.com/perl5.8.0/pod/perlthrtut.html - Perrin
Re: [mp2] integration with apache threads
[ Please keep posts on the list. I am not the most knowledgeable person here about threads, mp2, or XS code. ] Pavel Hlavnicka wrote: Thanks again, I'm solving following problem: generally may happen, that somebody has an instance of XML::Sablotron (and of few more packages) allocated in the interperter at the time, the perl is cloned. Sablotron objects are just wrappers around internal c++ structures, and the only data, they keep, are handles. Some of internal objects are thread safe and may be shared, some must be instantiated per thread. Any Perl data will be copied for you. Things at the C++ level will have to be taken care of by you. There may be a hook that you can use to do some work whenever a new interpreter is cloned. I already introduced threadsafe refcounting for all wrapped internals (bot of safe and unsafe) to prevent crashing in destructors (while disposing internal structure from several cloned instances), but currently I do need understand all scenarios, which may happen when handling non-thread safe internals. I need rather to write a documenation, about what the user is allowed, then develop a different model. In other words: I can keep all object happy when cloned to another threads due the refcounting, but I (user) must grant, that non-threadsafe instances are used across different threads. My original question was aimed right to this point: whether is such a situation even possible. It seems, it is. It it clear? have you got some more comments for me? There's no chance that the same Perl object will be used in multiple threads, but obviously multiple Perl objects could end up pointing to the same C++ data. I'd suggest asking how others are handling making their XS libraries safe across clone calls in a place like comp.lang.perl.misc where more XS wizards tend to hang out. There are some here too though. Anyone have a better answer for Pavel about how to deal with this? Thank you very very much Pavel
Re: Spell Checkers and EMail
Philip M. Gollucci wrote: We send a good deal of templated based E-Mail with the option to edit right before sending. The editing is done via webpage running under mod_perl/Apache or PerlEx/IIS with Oracle and MSSQL backends respectively. Anyone know of any good modules to add a spellchecker ability to this edit screen or possibly the one on the next page (submit button) ? If this is for an internal application where you have control over what browsers people use, there are several browser plug-ins and Java applets that provide in-line spell-checking on form inputs. - Perrin
Re: Help - Can Apache 2 Filters be implemented in Apache 1.3.x viamod_perl
On Thu, 2003-03-06 at 23:13, David Culp wrote: Can Apache 2 Filters be implemented in Apache 1.3.x via mod_perl [1.x]? No. However, there are a couple of method for doing this in 1.x. See Apache::Filter or Apache::OutputChain. - Perrin
Re: Reading an array from perl script
Stas Bekman wrote: As suggested by Mark, IPC::Shareable might work if the data set is small. If it's big you can use a simple dbm to store the data in and with proper locking read/write to/from it without disturbing each other. Yes, and the MLDBM::Sync module would handle that for you behind the scenes. - Perrin
Re: Apache::DBI on mp2
Stas Bekman wrote: FWIW, we are discussing the internal DBI pooling mechanism at the dbi-dev list and having already a sort-of-working prototype. So hopefully there will be no need for Apache::DBI in the near future, as DBI will be able to handle pooling internally. However it may take some time, as the drivers will have to adjust to support the new functionality. You can see the thread here: http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 Some working examples are attached to this message: http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html This is totally cool, Stas! Nice work. I look forward to answering yes when people ask if mod_perl has database connections pooling. By the way, to completely get rid of Apache::DBI this would need to cover the safety functionality in there as well, i.e. the pinging and the part where it rolls back any pending transactions when a a handle is returned to the pool. - Perrin
Re: Transparent front-end proxying for many VirtualHosts
On Wed, 2003-03-05 at 18:30, Andrew Ho wrote: I want to simplify my configuration in two ways. I'd prefer not to maintain two sets of VirtualHost configuration data, and I'd like it if the block that proxies .pl files to the backend proxy not be replicated per VirtualHost. As others pointed out, mod_macro is good for this. Personally, I tend to solve problems like this by generating my httpd.conf with a template and a tiny Perl script. That allows me to do absolutely anything in it, including looking up data from a database to use in the conf file. - Perrin
Re: prompting for secure data during startup.pl
Aaron J Mackey wrote: I need to make some secure data available to mod_perl handlers, without having it physically stored in a file, database, or named shared memory (since if someone can read the handlers' code, then they could read the sensitive data as well). So I need to prompt for it during server (re)start-up, and stuff it away into a lexical variable that only the handler can get at (i.e. another piece of code, or even another handler, that blesses itself into my handler's package still cannot access the data). Every httpd child process should have their own copy of the data. Is there a solution or cookbook recipe for this yet? What you're doing looks fine, as far as it goes. By making these variables part of a closure, you are making it impossible for people to read it directly with Perl code. Of course there is nothing you can do to prevent someone with full access to your server from running C code that will walk Perl's variables until it finds $secret. They could probably do this with creative of some of the B:: modules. - Perrin
Re: mod_perl headers
Cure wrote:
Does Apache submit headers when a error occurs ?
No. You sent the headers with your send_http_header command. Mason
doesn't have this issue because it waits and builds up the entire output
in a string before it sends any headers out. You can do the same in
your script if you want to.
Take a look at
http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_Errors_to_the_Client_Instead_of_error_log
for more info on these issues.
$r-('HI');
That's not a method of $r. Don't do that.
- Perrin
Re: mod_perl headers
Cure wrote: I know -- I submit the headers but why does it show the headers on the browser, doesn't that mean the headers wre submitted twice ? Why don't you take a look at the raw output (with LWP's GET script or something) and see? I misread your question before -- apache does send a hardcoded message with headers by default when your program crashes. In your case, you have also sent some headers but I think those will be buffered while the error headers will not, causing the effect that you're seeing. I can't advise you about why CGI::Carp isn't working for you. It might be caused by you already having sent some output at the time your script died. People often complain about CGI::Carp problems, so it seems to be a pretty fragile module. You can see some other people's discussions about it in the mailing list archives. They might have possible solutions for you. - Perrin
Re: Problems installing Apache (./configure)
mel awaisi wrote: Error: could not find any of these C compilers anywhere in your PATH: gcc cc acc c89 Well, you need to install a compiler. You must have chosen a set of packages that does not include development tools when you installed Red Hat. Look for their RPM of gcc and install it. - Perrin
Re: [error] Insecure dependency in unlink while running with -Tswitch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line106
On Fri, 2003-02-28 at 08:47, Martin Moss wrote: Is Apache::Session::DB_type Faster than Apache::Session::File? It depends on your disk, OS, and filesystem. It stores all the files in one directory, which is quite slow on some systems and not a problem on others. I already use a lot of DB connections and I used Apache::Session::File to reduce this, Apache::Session::MySQL (or Oracle, etc.) do not require separate database connections. If you already have a connection (which you would if you use Apache::DBI), you just pass it to Apache::Session. - Perrin
Re: [error] Insecure dependency in unlink while running with-Tswitch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pmline106
On Fri, 2003-02-28 at 09:10, Martin Moss wrote: I can't use Apache::DBI. I have multiple database connections.which are authenticated for different users. You're pretty much screwed then on the database front. I just wanted to reduce the database lookups. If you just want to cache data, don't use Apache::Session for that. Use IPC::MM, Cache::Mmap, Cache::FileCache, or MLDBM::Sync. - Perrin
Re: Apache is exiting....
Paolo Campanella wrote: I'm sure: [EMAIL PROTECTED] /root]# ps axf [...] 1212 ?S 0:00 httpd-modperl -f /etc/httpd/conf/httpd-modperl.conf 1215 ?S 0:00 \_ httpd-modperl -f /etc/httpd/conf/httpd-modperl.conf 1216 ?S 0:00 \_ httpd-modperl -f /etc/httpd/conf/httpd-modperl.conf 1217 ?S 0:00 \_ httpd-modperl -f /etc/httpd/conf/httpd-modperl.conf [get killer URL here] [EMAIL PROTECTED] /root]# ps axf | grep httpd-modperl 1288 pts/4S 0:00 \_ grep httpd-modperl 1215 ?S 0:00 httpd-modperl -f /etc/httpd/conf/httpd-modperl.conf 1217 ?S 0:00 httpd-modperl -f /etc/httpd/conf/httpd-modperl.conf 1284 ?S 0:00 httpd-modperl -f /etc/httpd/conf/httpd-modperl.conf [EMAIL PROTECTED] /root]# tail /var/log/httpd-modperl/error_log [...] Exception 415: UnableToReadFont (@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf) at /path/to/script line 584. [Fri Feb 28 14:31:49 2003] [alert] Child 1216 returned a Fatal error... Apache is exiting! That's bad. Sounds like an apache bug to me. Can anyone else confirm if this is intended behavior or not? You might want to check the httpd lists and newsgroups for info about this. - Perrin
Re: Apache is exiting....
On Thu, 2003-02-27 at 08:42, Paolo Campanella wrote: Pretend for a moment that you have no specific knowledge of the library which causes this problem: is there any black box approach to stopping some library's complaints from shutting down my web server? No. The library is executing C code in the web server process. There is nothing stopping it from simply saying exit(), or even segfaulting and killing that process. Note that it's just one process though, not the whole server. Not a big deal. You can sort of work around this by using a reverse proxy to separate your mod_perl server from your front-end web server. This gives you a scenario similar to CGI, and it's what FastCGI does, and Microsoft and other commercial vendors make a big fuss about doing this. However, the only advantage to it is that you can return a prettier error message to the user. It won't prevent anyone from exiting a process. - Perrin
Re: Apache is exiting....
On Thu, 2003-02-27 at 11:06, Paolo Campanella wrote: Just one thing though: when the process dies, it really does take the main server process down with it: [Thu Feb 27 17:55:04 2003] [alert] Child 8592 returned a Fatal error... Apache is exiting! Are you certain? Have you actually checked to see if the main server process PID is still running? If it crashes the parent process, that's bad. (You are running prefork MPM, aren't you?) - Perrin
Re: Authorization question
Jean-Michel Hiver wrote: Yes, but you're then making the authorization layer inseparable from your applicative layer, and hence you loose the interest of using separate handlers. It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. Then you have to keep that information in either cookies or URLs, and there is usually a need to talk to an external data database with a site-specific schema. The result is that plug and play auth schemes only work (unmodified) for the simplest sites. - Perrin
Re: Authorization question
Jean-Michel Hiver wrote: It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. How do you mean, 'nobody'? Users certainly don't mind! Sure they do. They want a nice HTML login screen, and features like remember this login on this computer (using cookies) which is standard on most major sites now. I admit that it's hard to get away without cookies and URI encoding schemes, but not impossible. There's a lot of tricks that you can do with path_info... But path_info is URI encoding. Also, most of the auth/access modules, including ones that stick to the auth and access phases, use cookies or URIs. There really is no other option except basic auth. If you build a generalized auth system, there may well be other people interested in it. However, it would have to be very easy to change the mechanisms for maintaining state (cookies, URIs, basic auth) and checking credentials (any kind of database with any kind of schema). The latter probably means some custom development on every installation. - Perrin
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
md wrote: --- md [EMAIL PROTECTED] wrote: Is it possible to have row-level locking (as opposed to table-level or null locker) with MySQL 4.x and Apache::Session? You effectively have that already, since the MySQL locker only locks an individual session. Check the code. Looks like I get that with InnoDB automatically... You can use actual transactions there. Try starting with the Apache::Session::Store::Postgres module and hacking it a bit. There is no module available that was designed for use with Innodb MySQL tables. - Perrin
Re: Scripts and HTML docs in the same directory (+ modperl newbieexperiences)
On Wed, 2003-02-26 at 23:16, Mark James wrote: One question: Prior to using mod_perl I was able to have unsuffixed scripts and .html files residing together in the server root directory by using Apache's Files directive to force the scripts to be executed: e.g. Files db ForceType application/x-httpd-cgi /Files I can't seem to do this with mod_perl because I now have to use a SetHandler directive on the directory You should be able to do the SetHandler inside a Files directive just like you did with ForceType. Have you tried that? - Perrin
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
md wrote: Also, we'll soon be adding a substantial number of users to our system and I wonder if it would be wise to move away from the table locking that is currently being used with Apache::Session::MySQL. It would be. Frankly, there is no value to the kind of mutual exclusion that the Apache::Session locking provides in a typical web application. If you use the null locker you will still get atomic updates, but you will have the possibility of someone opening up two browser windows, hitting submit in both, and having the last save overwrite the values from the first one, possibly losing some changes. In most web apps, that is not a big problem. Note that this could become a problem if you use sessions incorrectly by putting tons of data in them. Most of your data should have its own normalized tables and persistence code. Sessions are for storing tiny little bits of data like the user's ID or some form data that from a multi-page form that hasn't been committed yet. I'm looking at Apache::Session::Flex and setting Lock='Null'...however, I get the impression from an old email (see below) that Flex is for debugging only. If you look at the actual contents of Apache::Session::MySQL, you'll see that it's essentially just a config file. There's no need to be concerned about using Flex, but you could easilly code up your own Apache::Session::MySQLNoLocks by changing a line in the current module. First, any benchmarks on what kind of load I can realistically use with Apache::Session::MySQL? It all depends on how much data you put in (lots of data in the session will slow things down) and how fast your database is. At eToys we used a slightly hacked version of Apache::Session::DBI with Oracle and it handled more traffic than most sites will ever see. - Perrin
Re: mod_perl examples
On Mon, 2003-02-24 at 00:14, Christopher Hahn wrote: The examples from the O'Reilly book Writing Apache Modules with Perl and C do not compile because of a missing Apache::Src module. I am using Apache 2.0 + mod_perl-1.99_08 and can only find docs on this module under the 1.0 section of the mod_perl 1.0 area of the mod_perl website (http://perl.apache.org/docs/1.0/api/Apache/src.html). That's right, that book only applies to mod_perl 1.x. If you want documentation on using mod_perl 2 there is only the documentation on the website at this time. - Perrin
Re: Apache::Session and Postgres
On Mon, 2003-02-24 at 07:09, Grant McLean wrote: I get this error: Can't locate object method get_lock_manager via package Apache::Session::Postgres And indeed, that method does not seem to be defined in any of the modules which Apache::Session::Postgres inherits from. I don't see anything that calls that method anywhere in the Apache::Session distribution. Either you have some code doing it, or you have an old version. You should be running the 1.54 distribution. - Perrin
RE: child-parent memory access / mod_perl / shared mem/inter-proccess communication , etc..
On Mon, 2003-02-24 at 05:40, Jim Morrison [Mailing-Lists] wrote: Hmm.. Yes, it sounds pretty sketchy to me too! Immediately what I am playing with is the idea of keeping parsed XML (XML::LibXML)in memory between requests. Is this a completely barmy idea? Caching is a good idea, but it's not possible to share objects between Perl processes without serializing them. Try using Cache::Mmap, Cache::FileCache, or MLDBM::Sync. - Perrin
Re: child-parent memory access / mod_perl / shared mem / inter-proccesscommunication , etc..
Jim Morrison [Mailing-Lists] wrote: Sniff.. I've kind of got something working... Enough such that one httpd can request an XYZ, and if a second httpd comes along a little later and requests the same XYZ then it will get it from shared memory. I hope you used one of the modules I suggested rather than writing the whole thing from scratch. As expected though.. trying to do this with LibXML objects fails.. a lot. LibXML is an XS module, so that may interfere with serialization. CAVEAT : I know it's probably looked at as a silly idea, but if I could keep my parsed stylesheets/xml's shared somewhere I'd save my self having to re-parse for every request wouldn't I? . . Why don't you try caching the results instead? - Perrin
Re: child-parent memory access / mod_perl / shared mem / inter-proccesscommunication , etc..
Matt already answered most of your questions. Jim Morrison [Mailing-Lists] wrote: And I'm getting some mileage out of experimenting with this anyhow - if it doesn't work for LibXML it looks like it could be very useful for other stuff, and if it ever works bug-free(-ish) I'd like to give something back to all the CPAN-people who've written things I use.. No offense, but you are reinventing the wheel. There are many modules available for sharing cached data. They all use Storable, so none will work on LibXML objects, but they are pretty well-known and mature modules: Cache::Mmap, Cache::Cache (which includes an option to use IPC::Sharelite), IPC::MM, MLDBM::Sync, etc. - Perrin
Re: Apache module
On Mon, 2003-02-24 at 19:49, Carl Holm wrote: Does anyone know where to find the Apache module mentioned (use Apache;) in the tracking users with cookies code example code found in the Apache::Session manpage? It's part of mod_perl. If you have installed mod_perl 1.x, you have it.
Re: Apache module
[please keep it on the list] Carl Holm wrote: I'm running mod_perl2 The examples in the documentation of Apache::Session are for mod_perl 1.x. If you want to run them under mod_perl 2, you have to port them or use the backward compatibility functions. Documentation is on the perl.apache.org site. Note that these examples are pretty trivial and should not be hard for you to port. Apache::Session itself is in no way tied to any version of mod_perl. - Perrin
Re: child-parent memory access / mod_perl / shared mem /inter-proccess communication , etc..
On Sun, 2003-02-23 at 10:46, Jim Morrison [Mailing-Lists] wrote: Having spent the w/e getting to grips with startup.pl's and the such I'm beginning to discover that it's only possible to share read-only memory and as soon as you write to memory it splits off.. .. The situation with forked Apache processes is the same as with any forked process: you have to use some form of IPC to communicate between them. I suggest you look at IPC::MM or IPC::Shareable. IPC::Shareable is more transparent, but IPC::MM has better performance. IPC::MM simply creates a hash in shared memory and lets you write to it. Either of these will allow you to share data between processes. What I really want to do is to write a module that can be accessed from any of the child apache processes such that some work can be done at one stage, and if the second request comes through to another child, that child can pick up on the work of the first.. That sounds pretty sketchy to me. Why are you trying to do that? There may be a much simpler way to achieve what you're after. Is there _absolutely_ no way that two children could ever have write access to the same object? No, not when there are multiple processes involved. The sharing that happens with the modules I mentioned above involves serializing Perl data into a byte stream, putting it into shared memory, and then pulling it back and de-serializing on the other side. Lastly, coming from a RiscOS background, it was always possible to issue module interrupts such that one program can call the functions of another completely separate program.. You have the basic Unix building blocks here: signals, semaphores, shared memory, sockets. It seems to me I'm missing some pretty basic inter-program communication stuff.. but then all my experience of calling one linux prog from another has usually worked by piping something from one to another. You can talk between processes on STDIN (which is what a pipe is doing) if the process you want to talk to is listening on STDIN. Web server processes don't do that. They listen on sockets for requests from outside. - Perrin
Re: mp2: any recommendations for template systems yet?
On Fri, 2003-02-21 at 16:10, Udlei Nattis wrote: you can use Ananke::Template is one version of template::toolkit but very very very very fast I wouldn't really call it a version of Template Toolkit. It's much more like HTML::Template: a very streamlined templating tool with an intentionally limited mini-language. The mini-language used looks like Template Toolkit but is functionally equivalent to HTML::Template. Template Toolkit has many other features and a much more extensive mini-language, which is presumably why someone would choose to use it. Ananke::Template would be more appropriate for someone whose needs are met by HTML::Template but who prefers the look of the TT tags. - Perrin
Re: Apache::TicketAccess
Scott Alexander wrote: I'm trying to use the example from the Eagle book on page 309 - 314 using the TicketAccess, TicketMaster, TicketTool handlers. In TicketMaster in sub go_to_uri it sets the a cookie with the $ticket. I can print $ticket to error log to see what it contains. But for some reason the cookie never gets set. I haven't used these modules, but I suggest you do some further debugging. Try looking at the headers being sent back from the server and see if it is sending the cookie header or not. Try going straight to it without going through the proxy. Find out what is actually happening. Then you'll have a better idea what needs to be fixed. By the way, most people use CPAN modules for this rather than the stuff in the Eagle book. Look at things like Apache::AuthTicket or Apache::AuthCookieURL. (I don't have a use for any of these modules, so I can't personally recommend one.) - Perrin
Re: mp2: any recommendations for template systems yet?
On Thu, 2003-02-20 at 22:27, Carl Brewer wrote: Do any of you have any recommendations for template systems with mp2? Not of the religious kind (!) but more on the lines of what's working with mp2 at the moment? Everything that doesn't make mod_perl API calls should work without changes. That means HTML::Template, Template Toolkit, Text::Template, CGI::FastTemplate, etc. Without wishing to start anything religious ... any suggestions for a template system that handles sessions? Apache::ASP, Embperl, and Mason all have session support integrated now. I can't vouch for their stability on mp2 yet though. I'm not adverse to HTML::Template and Apache::Session if it'll work with mp2. Since Apache::Session has nothing to do with mod_perl, it will work fine on mp2, or CGI for that matter. - Perrin
Re: help with Apache::DB
On Tue, 2003-02-18 at 08:07, giorgos zervas wrote: i am using Apache::DB to debug my mod_perl handlers and altough the debugger seems to be working fine it won't display the source code next to the current line being debugged. That's because you are compiling that code before you activate the debugger, so it doesn't get to put in the debugging symbols. Look at the init method in the Apache::DB documentation. - Perrin
Re: mod_perl 2 apache::session and or die
Chris Faust wrote: All works well except when there is any kind of problem in the script where the condition will die.. [...] When this happens everything to do with that script is unresponsive - I know that is a little vague but that is the best way I can describe it. What happens is the error comes up (standard server error) and that is the last thing that is logged, if you try to go back and refresh the hourglass will go for hours and nothing happens and nothing is ever logged It sounds like a locking problem to me. I'm guessing that mod_perl 2 is not calling the right hooks when it traps a die() to trigger the DESTROY method in Apache::Session which releases all locks. You can find out exactly what's going on if you run it in the debugger (Apache::DB) or throw some debug logging into Apache::Session to find out where it gets stuck. This is the beauty of having the source code. - Perrin
Re: Please wait Handler
Martin Moss wrote: I was wondering if it is possible to Create a Handler that points a user at a page with an animated gif saying something like Please wait, and then when my other handlers have finished display the page results I want from my mod perl handlers. The classic answer to this problem is described by Randal in one of his Web Techniques columns: http://www.stonehenge.com/merlyn/WebTechniques/col20.html You can also try server push (with the Content-type: multipart/x-mixed-replace header), but I'm not sure how consistently today's browsers implement that. - Perrin
Re: Please wait Handler
Andrew Ho wrote: Make an HTML page which does a form submit to pleasewait.pl. pleasewait.pl just displays an HTML page with an animated please wait image on it, and its headers include the following header: Refresh: 1; url=http://www.example.com/getresults.pl?args... That's what Randal does in the article that I posted (although his puts it in a META tag). It's called client pull, and was introduced by Netscape at the same time as server push. - Perrin
Re: Has Apache::Cookie been ported to mod_perl-2 yet?
[EMAIL PROTECTED] wrote: No it hasn't. Need to use CGI::Cookie for the time being. Apache::Cookie and Apache::Request I believe are both either provided by or dependent on libapreq, which is still a work in progress for apache2/mod_perl2. That's the biggest reason I'm still using Apache 1.3.x now. Incidentally, I recommend CGI::Lite. It's very small and fast, and has an API close enough to Apache::Request that you could easilly convert your code later. Handles cookies as well. - Perrin
Re: Apache::Registry incompatible with CGI ?
Rob Lambden wrote:
sub SetupPageArguments()
{
my ($DB, $nLoop, @Query, $Key, $Value);
$DB=shift;
@{$DB-{Page}-{'.parameters'}}=$DB-{ApacheReq}-param();
for($nLoop=0; $nLoop=$#{$DB-{Page}-{'.parameters'}}; $nLoop++)
{
if(!defined($DB-{ApacheReq}-param($DB-{Page}-{'.parameters'}[$nLoop]
)))
{
$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}[0]='';
}
else
{
@{$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}}=$DB-{ApacheReq}-
param($DB-{Page}-{'.parameters'}[$nLoop]);
}
}
What's the purpose of that loop? Is it just to copy the data out of
Apache::Request/CGI? I would do something a little more compact, like this:
my @keys = $DB-{ApacheReq}-param();
my %param_hash = map { $_, [ $DB-{ApacheReq}-param($_) ] } @keys;
$DB-{Page} = \%param_hash;
$DB-{Page}-{'.parameters'} = \@keys;
However, when I send a large block of data in with the
request I have found
that portions of the middle are left out. Putting the old code back
means that the whole of the
text is seen.
Have you tried debugging the individual parameters to see exactly which
ones(s) are getting munged? Print them out in both versions and compare
them to see where the data is being lost.
- Perrin
Re: Use DBI in http.conf
Wes Cravens wrote: I have a number of PerlModule Library::Module Location '/Module' SetHandler Perl-Script PerlHandler Library::Module /Location Type configs. I can very easily extract this information from a database. Or you could use Apache::Dispatch, or you could put them in a simple text file, or you could use mod_macro. I'm sure it would work to put them in DBI (although you'd better close that connection before Apache forks!), but then you have a bunch of config data that can only be changed by messing with SQL and can no longer be easilly viewed, diffed, versioned, etc. - Perrin
Re: $^T
H Jayakumar wrote: In windows mod_perl-beta2 print $^T; returns the same value again and again That is correct behavior. The $^T variable contains the time that the current program (i.e. apache) started running. If you want the current time, use time() instead. - Perrin
Re: libgtop gone?
http://ftp.gnome.org/pub/GNOME/desktop/2.0/2.0.3/sources/libgtop-2.0.0.tar.gz Thanks to both of you for pointing out that it's on the Gnome FTP site. I'll send Doug a documentation patch to point to this location. - Perrin
Re: [OT] Gkrellm (was: RE: libgtop gone?)
Narins, Josh wrote: Um, can someone provide a link as to what libgtop is supposed to do? Is it just a graphical /usr/local/bin/top? There is a graphical top built on it, but libgtop is just a library that measures memory usage, CPU, etc. GTop.pm is a module which provides a Perl interface to that data. It is referred to in many parts of the mod_perl documentation, like this one: http://perl.apache.org/docs/1.0/guide/performance.html#Measuring_the_Memory_of_the_Process It is the basis of the Apache::GTopLimit module and is used by Apache::VMonitor. - Perrin
Re: DBM ties within Apache under Mod Perl
Jim Morrison [Mailinglists] wrote: One of the things I understood mod_perl allowed you to do is to tie a Hash/DBM to the top apache process, so that it's always available throughout the other apache processes? You can only do that for read-only dbms. For read/write, use MLDBM::Sync. PS. Do people think this is a bad idea from the start? Yes. For one thing, there is no way to know when people leave your site. - Perrin
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
[EMAIL PROTECTED] wrote: I'm not sure whether the company that's hosting my web site will want to install any non-critical module (They ahve done me a favor allowing me to run mod_perl ... ) So I want to see if I have any options installing it under my directory tree. Okay. You need to modify @INC then. Take a look here for examples: http://perl.apache.org/docs/1.0/guide/config.html#The_Startup_File - Perrin
Re: do as temp solution for require problem ?
[EMAIL PROTECTED] wrote: This is working fine although a mysql database connection in a subroutine in an external file doesn't always work. Please explain. It shouldn't ne a problem to run code that makes a database connection in a separate module. - Perrin
Re: Newbie Q on Apache::Include
[EMAIL PROTECTED] wrote: Can someone direct me to a good tutorial for Apache::Include? What are you trying to do? All it does is add one extra directive to mod_include, allowing you to call a Perl script in-line. If that script is run under Apache::Registry, you don't even need to do that; you can use the normal syntax for a virtual include. - Perrin
Re: do as temp solution for require problem ?
[EMAIL PROTECTED] wrote: If you look at the previous mentioned site, you can see there is only one file, but it contains a lot of includes. - a random function for the banners on top - a file for the navigation on the left which includes a file for the date and a file for the counter (mysql database) - the content pages with different files for the forms redirected per OS and type of Browser. You seem to be talking about including chunks of the page, like server-side includes (SSI). That's not the same as doing a require/use on a module. Modules are for storing chunks of Perl code, not HTML. You originally asked about why your subs from required files were not working. That's what Stas and Randal are telling you: you need to make them into real modules with package declarations. There are other ways to do it (like do) but they are kludges. If you're looking for something to help you manage splitting pages up into chunks of HTML, you should consider either using SSI (!--#include virtual=/perl/example.cgi?argument=value --) or using HTML::Mason, which is based around that idea. - Perrin
Re: Newbie Q on Apache::Include
[EMAIL PROTECTED] wrote:
My personal web site has both static and dynamic files. The static files
have a kind a look template maintained by using XSSI. For the dynamic
files I wanted to somehow be able to do the same thing using the same
files so that I don't need to maintain 2 sets of files. Of the set of
scripts there are some that handle forms. I could have the shtml include
the script and pass on the query_string. But I want these to be of type
POST. So I can't have the form handler to be an shtml file (having the
look) which would call (!--#include ) the cgi script. I need the
opposite - parsing of the script output.
Then I thought I would check if it was possible with mod_perl and found
Apache::Include. This seemed promising to achieve what I would like to
do - use the same files (that maintain the look of my web site) for both
the static and dynamic pages.
You can do this. Technically I think you can POST to a file, but you
don't need to.
You can do this lots of ways, including post-processing the output of a
CGI script with a module like CGI::SSI. What I would suggest is writing
a script that you will run under Apache::Registry, and calling
Apache::Include-virtual('/uri/of/file') to do the includes.
- Perrin
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
[EMAIL PROTECTED] wrote: Tks that way worked except for the #config sizefmt of mod_include That should work fine. What's broken with it? From the documentation of the Apache::Include I couldn't make out whether it handled other features like set which I am using. It does not implement SSI, it just integrates an extra tag (#perl) into mod_include. Everything that works in your current mod_include pages should continue to work. But your siggestion led me to search on CPAN and found Apache::SSI. Apache::SSI is good too. It will use more RAM, but it is slightly faster than mod_include. - Perrin
libgtop gone?
I pointed someone at some mod_perl documentation that suggested installing GTop to measure shared memory, but he was unable to find libgtop for download at the URL in that module. I investigated and I don't see it anywhere! Is libgtop gone? Did it get replaced with something else? Any Gnome followers here who can shed some light on this? - Perrin
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
[EMAIL PROTECTED] wrote: !--#config sizefmt=Mb -- works with mod_include Got a [an error occurred while processing this directive] (well actually the errmsg that I had set) with CGI::SSI. As I said I didn't really follow-up to see if this is a prob. Oh, sorry, I missed the part about CGI::SSI. That will work with mod_include (and thus with Apache::Include). It does not implement SSI, it just integrates an extra tag (#perl) into mod_include. Everything that works in your current mod_include pages should continue to work. Oh kinda like embedding perl code in an shtml? It lets you run any Perl subroutine in the middle of a page. It also lets you include files (a virtual include) from within a Perl script by calling the Apache::Include module. Actually I haven't got this to work. I'm yet trying to figure how to load the module (PerlModule Apache::SSI) in the .htaccess with it actuall residing in the /perl/ directory rather than the standard lib directories. Why? It's a module, not a CGI script. If you don't want to put it in your standard @INC paths, you can put it under APACHE_HOME/lib/perl/ which is automatically added to @INC by mod_perl. - Perrin
Re: libgtop gone?
Stas Bekman wrote: It's integrated into the gnome project and doesn't really exist as a standalone thing. At least I couldn't find it. When you install the gnome desktop, you get libgtop as well. So if you are on linux, simply check your distro for this package. e.g. use: http://fr.rpmfind.net/linux/rpm2html/search.php?query=libgtop in the worst case use the above resource to grap the src.rpm and then extract tar.gz from there. This guy was on HPUX, and he just wanted source to this one library. It used to be available separately. I guess it's not a simple thing to do at this point if you don't want gnome and aren't on Red Hat. - Perrin
Re: [mp2] Connection pool with Apache::DBI and Oracle
Georg Botorog wrote: I don't understand. The Apache server I am using has 50 ThreadsPerChild If you want help with mod_perl 2, you need to say so. Otherwise it is assumed you are using 1.x. Put [mp2] in your subject line. Thus, Apache is able to handle quite a few requests simultaneously. However, Oracle has only one session for the job. Each thread has its own Perl interpreter and each one of those will have a persistent DBI connection when using Apache::DBI. Nothing is shared between threads unless you explicitly make it shared. There is currently no way to share DBI handles between threads. If you're interested in working on that problem, you can read the archived posts on the topic. As I mentioned in the last message, sharing doesn't help much unless you have a lot of mod_perl code that doesn't use database connections. As a consequence, starting two identical requests from distinct clients leads to blocking the second request until the first one is served. Absolutely not. There is no sharing and thus no blocking. - Perrin
Re: [mp2] Connection pool with Apache::DBI and Oracle
Georg Botorog wrote: Actuallly, I had no idea I am using mp2. I have downloaded some time ago a bundle with Perl, Apache, etc. (for NT), and I'm still using it today. Ah, okay NT is another key piece of information. Sorry, I don't use apache on NT so I thought that was a mp2 directive. So, you are using 1.x on NT. With 1.x, all requests are handled serially on NT, which explains the behavior you're getting. It's actually not related to DBI at all. See http://perl.apache.org/docs/1.0/os/win32/multithread.html for the full story. - Perrin
Re: Connection pool with Apache::DBI and Oracle
Georg Botorog wrote: More precisely, I am using Apache::DBI to create and cache the connection to the DB. As this connection uses a single Oracle session, it is obvious that it becomes a bottleneck. Apache::DBI uses one connection per process. There is no bottleneck there. Each process only handles one request at a time so it would have no use for more than one database connection. Ideally, one would have a pool of DB sessions (= DB handles) that the Apache threads would use in serving the requests coming from clients. That's only ideal if your code spends a lot of time doing things that don't involve a database. You shgould be running with a reverse proxy in front, so that mod_perl processed will not be serving static files. Alternatively, is it possible to convince several Apache servers running concurrently to cooperate (i.e., load balance) in answering incoming requests? If yes, how? Any load-balancer will do that. There are dozens, both commercial and open source. See the mod_perl documentation for a list you can start with. - Perrin
Re: mysql question
Calm down folks. Anyone can make a mistake. This is a diverse list with many different levels of Internet experience represented, and one off-topic post is not a big enough problem to merit banning people. General list etiquette is discussed here: http://perl.apache.org/maillist/email-etiquette.html Please take care to choose the right place to ask this sort of question in the future. Thanks, Perrin
Re: mysql password encryption
Martin Moss wrote: the problem I have is that I store the password in the database as a Password field. However when I wish to use DBI to connect to another mysql database I cannot use the Password stored in the database as it comes out encrypted. I really don't want to store the unencrypted password anywhere on the system. Is there a way to let DBI/mysql know that the password I am giving them is ALREADY encrypted? Why don't you just encrypt it yourself and store it in a VARCHAR? - Perrin
Re: server startup shutdown
[EMAIL PROTECTED] wrote: I have XML file and don`t want parse/serialize on each request how implement this: 1) XML parsed on startup 2) All modules work whith same object It doesn't look to me like you can share objects across threads effectively at this time. You can share a hash ref, but that doesn't share things tha are referenced within that hash and it doesn't share the blessing. I think you will need to do this using standard data sharing methods, like IPC::MM or MLDBM::Sync. 3) XML serialize on server shutdown That sounds dangerous. What happens if your server crashes or otherwise shuts down abnormally? You will lose everything. Much safer to write your updates to disk, even if you only do it with Storable or MLDBM::Sync and then transform it back to XML later. - Perrin
Re: Configuration in module vs in apacheconfig...
Marcin Kasperski wrote:
After some initial consideration I found, that moving config from
MyConfig.pm to myapp.conf does not seem to be reasonable. Imagine
PerlSetVar'ing arrays and hashes which can refer one to another...
If you can do it in a module, you can do it in myapp.conf.
Perl
package MyConfigPackage;
use vars qw($complex_var);
$complex_var = { 'foo' = [ 'bar', 'baz' ] };
/Perl
Personally, I've been pretty happy to keep two config files, since the
distinction seems pretty clear to me.
- Perrin
Re: [mp2] e-Commerce
Nick Tonkin wrote: Hmm, I think it all depends on the application. It's true that hardware costs have declined since The Days, but you still don't have unlimited RAM. True, there is an upper limit on per-machine scalability with a multi-process server and thttpd would do better there if the network connection is not already saturated. In our case we benchmarked thttpd vs. a stripped apache 1.x and the performance was so close that we decided to go with the simpler route of using apache, which gave us SSL for images and the ability to run a single server for proxy and static page requests. It also made it easy to set Expires tags on images. One possible factor in our good apache performance is the high locality of access for our static files. There was a very good chance that any requested file would already be cached in RAM. ValueClick was probably just the opposite. - Perrin
Re: [mp2] e-Commerce
Stas Bekman wrote: Where did you see the benchmarks showing that Apache 2.0 has a better performance than 1.3? All over! Joshua's numbers from this list: http://marc.theaimsgroup.com/?l=apache-modperlm=103238123915307w=2 Some good graphs, including thttpd: http://www.zeuscat.com/andrew/work/aprbench/ Someone's random benchmark from Google: http://www.vomjom.com/docs/apache_benchmark.php I've seen other random posts too, which I can't find at the moment. Note that ZDNet found no improvement over 1.x on Linux when they benchmarked it, but it was version 2.035 and there could be other factors as well. http://www.eweek.com/article2/0,3959,15300,00.asp - Perrin
Re: Testing
Michael Hyman wrote: I am interested in how people setup their Apache 1.3.x servers to run mod_perl'able code. Not, how to get mod_perl to run something, we do that with rewrite rules. I am more interested in config settings that control for performance and stability. There is lots of documentation about performance tuning in the on-line documentation. http://perl.apache.org/docs/1.0/guide/performance.html is a good place to look. I am also very concerned about testing. How do you test a mod_perl system to make sure there is no memory corruption from one instance of an app to another. What do you mean by memory corruption? The only sharing that happens between processes is what your OS does magically through copy-on-write. Is there any documentation on testing a mod_perl app? I have yet to find anything. There is plenty about this in the on-line docs too. See http://perl.apache.org/docs/general/testing/testing.html. - Perrin
Re: [mp2] e-Commerce
Eric Frazier wrote: On that note, how about just using Apache2 for the proxy front end, and mod_perl /apache 1.x for the back end? I have wanted to try to avoid the thttpd stuff for images and from what I have heard about apache2 it can handle static pages a lot faster than the 1.x did. You really should be able to get more than enough performance out of 1.x for static files, unless you are using very old hardware. We used a slim 1.x build with mod_proxy, mod_ssl, and mod_rewrite for all of our static files at eToys and it ran like a champ. It's true that both thttpd and apache 2 have better performance, but web server performance on static files is almost irrelevant on today's hardware because you fill your bandwidth up long before anything else becomes an issue. - Perrin
Re: Apache::Session::File hangs
Axel Huizinga wrote: The following code hangs after reloading and the try to tie again the previously created session! WHY? ... use vars qw( $id $sID $lockDir %session $sessionDir ); The session variable has to go out of scope for the lock to be released. I know it seems like the untie should do it, but try making %session a lexical instead of a global. - Perrin
Re: using ALRM signal in mod_perl script
Plamen Stojanov wrote: is it save to use ALRM signal in my mod_perl script. I hook a handler there, to unlock my semaphores in emeregency. It should work, but you'd be better off with a cleanup handler. - Perrin
Re: crazy problem
Ray Zimmerman wrote: I have a bizarre problem and I've run out of ideas ... Here's the gist ... when I run some code which looks like ... my result = `/usr/local/bin/matlab input_file.m`; ... from a perl CGI, then matlab (a commercial math package) segfaults. However, when I run it from mod_perl on the same server it runs fine (it runs fine from the command line, btw). Something is different. Environment variables, PATH, user, current directory, etc. You have to go through all of them until you find the one that's the problem. Depending on how your server is set up, CGI could be executing as a different user. - Perrin
Re: Determining when a cached item is out of date
Christopher L. Everett wrote: But I haven't been able to wrap my skull around knowing when the data in Mysql is fresher than what is in the cache without doing a major portion of the work needed to generate that web page to begin with. There are three ways to handle cache synchronization: 1) Time to Live (TTL). This approach just keeps the data cached for a certain amount of time and ignores possible updates. This is the most popular because it is easy to implement and gives good performance. Cache::Cache and friends work this way. 2) Polling. This involves checking the freshness of the data before serving it from cache. This is only feasible if you have a way to check freshness that is faster than re-generating the data. This is difficult in most situations. 3) Invalidation. This approach involves removing cache entried whenever you update something that would make them out of date. This is only feasible if you have total control over the update mechanism and can calculate all the dependencies quickly. One more thing. Perrin Harkins' eToys case study casually mentions a a means of removing files from the mod_proxy cache directory so that mod_proxy had to go back to the application servers to get an up to date copy. I haven't seen anything in the mod_proxy docs that says this is possible. Does something like that exist outside of eToys? Not in mod_proxy. We added it ourselves. I don't have the code for that anymore, but it's not hard to do if you have a competent C hacker handy. Maybe mod_accel has this feature. - Perrin
Re: Determining when a cached item is out of date
Christopher L. Everett wrote: I see where one could combine polling and invalidation, for instance by having empty files representing a page that get touched when the data for them go out of date. More commonly you would combine TTL with invalidation. You use invalidation for the simple stuff, where people need to make instant updates they can see, and you use TTL to catch everything else. But again, there is the issue of mapping changed data onto dependent pages. Tracking dependencies gets difficult quickly, and that's why almost no one does it. TTL is very efficient, if you can live with data being out of sync for a little while. - Perrin
Re: Load balancers
John Siracusa wrote: But meanwhile, we're still open to alternatives. Surprisingly, there don't seem to be many (software) options. (A hardware load balancer is not an option at his time, but I'll also take any suggestions in that area :) I've always used hardware ones. I believe big/ip does everything you need. However, if I were going to use a software solution I would be looking at Linux Virtual Server, probably starting with the Red Hat offering based on it. This brings me to the mod_perl angle. Has anyone ever tried using a slimmed down mod_perl server as a load balancer? Is this feasible? Not a good idea. It would eat all your memory. You'd be much better off with the mod_rewrite solution mentioned in this thread. - Perrin
Re: Load balancers
John Siracusa wrote: The mod_rewrite solutions lack dead server detection, and that's something I'd rather not try to roll on my own, especially after seeing how well (or not, actually) existing software solutions do. But I've added it to the list. ... It's kind of disappointing to hear that the mod_perl solution it probably not feasible. Perl solutions are always more fun to implement ;) The mod_rewrite option is a Perl solution. You would write some Perl code to manage the availability checks and optionally to provide a new load-balancing algorithm. It's very similar to using mod_perl for it, except you get to skip writing lots of annoying proxy code. - Perrin
Re: Load balancers
John Siracusa wrote: But in a full-fledged mod_perl solution, I could back out gracefully and retry another server if I happened to initially choose a dead server before my dead server detection code caught it. That sounds cool, but how important is it really? I'm not sure any of these solutions (including the commercial ones) do that level of seamless failover effectively. - Perrin
Re: Shared memory 'copy-on-write' issue
Anton Permyakov wrote: reading http://perl.apache.org/docs/1.0/api/Apache/SizeLimit.html#Shared_Memory_Opti ons i am seeing that link about memory sharing by copy-on-write points to http://perl.apache.org/docs/1.0/guide/index.html and 'META: change link when site is live' stands after it. Site is alive, how knows where should this link point to? It does go the guide correctly, but a more specific link would be this: http://perl.apache.org/docs/1.0/guide/performance.html#Sharing_Memory - Perrin
Re: OSCON ideas
Larry Leszczynski wrote: On Wed, 8 Jan 2003, Perrin Harkins wrote: 2) The Perl Pet Store This would be a discussion of porting the J2EE Pet Store reference application to Perl. It would cover Perl equivalents for various J2EE features, and talk about what was easier or harder to do in Perl. I think this could make for an excellent talk. Along similar lines, I'd be interested in hearing about Perl application frameworks such as OpenInteract, progress of P5EE, etc. - any ammunition I could use that would help displace the misconception that if an app server/framework is required then it must be Java-based. Several people have brought up benchmarking in reference to the pet store. I don't think it will possible to do a good benchmark of this application, partly because it's so big (it's a reference app that uses lots of functionality just to demonstrate it) and partly because it's well known that the J2EE pet store performs badly. It does not represent anyone's best efforts to make a high-performance Java store. If people are more concerned with seeing something that would dispel myths about Perl performance, rather than a talk on feature portability from J2EE to Perl, I could look at implementing something that really can be benchmarked like the TPC-W spec or the Doculabs Nile Bookstore benchmark. These would be more comparable to existing Java and .NET performance tests. Personally it would warm my heart to help enable a press release saying something like Perl blows away previous price/performance leaders on TPC-W benchmark, but I don't know if hearing about that would be as interesting to people as the other things I proposed. Regardless, I think that posting a good reference implementation of one of these specs might get mod_perl some good attention from the business-oriented mags that usually focus on Java, and would be a valuable marketing tool. - Perrin
Re: Anyone ever have Apache::Session::File files getting corrupted?
[EMAIL PROTECTED] wrote: Anyway, my question for now is whether anyone has seen corruption like this with Apache::Session::File in your typical multi-user mod_perl web app environment? I think most people don't use Apache::Session::File in production. It's more of a testing thing. In your situation, you would probably get great performance from MLDBM::Sync with SDBM_File. I'd suggest trying that if you can't determine the cause of the Apache::Session::File issues. - Perrin
Re: Query
George Valpak wrote: Sounds like you need 2 apaches, on separate physical servers - I agree, the proxy approach is your best choice, and it gives other performance benefits as well, described in the documentation. - Perrin
Re: Sticky pnotes conclusion
John Heitmann wrote: That example makes us look pretty dumb, let me explain how it happened since it may affect you too. We do inter-request caching of $dbh in pnotes. We rely on the destructor of DBI to disconnect; we don't use disconnect() anywhere in our code. We do however use Apache::AuthTIcket-- which does disconnect-- and we pass it our cached $dbh. So you can see how the above example could occur: AuthTicket grabs a dbh, then disconnects it, we still use it because we assume it is connected like normal, but the DBI doesn't like that sequence of events (it recovers the connection, but leaks). It doesn't seem necessary for Apache::AuthTicket to do that. However, people using Apache::DBI would not have a problem with this since the disconnect doesn't actually disconnect. - Perrin
OSCON ideas
As many of you probably know, the call for participation in this year's Open Source Conference has gone out (http://conferences.oreillynet.com/cs/os2003/create/e_sess). I'm thinking about possible talks to submit and I want a little feedback on what people are most interested in. Here are two options I'mconsidering: 1) Database Objects in Perl This talk would focus on the database mapping options for Perl, including modules like Tangram, Class::DBI, SPOPS, etc. It would examine the differences in features, ease of use, and performance and include a set of hand-coded classes using straight DBI for comparison. 2) The Perl Pet Store This would be a discussion of porting the J2EE Pet Store reference application to Perl. It would cover Perl equivalents for various J2EE features, and talk about what was easier or harder to do in Perl. Because of the size of the Pet Store codebase and the complexity of the environment required to run it (multiple databases, etc.), it may not be possible to do a good performance benchmark. However comparisons on other fronts (amount of code, ease of maintenance, etc.) would be made. What do you guys think? - Perrin
Re: Query
Chandrasekhar R S wrote: I am having a requirement as follows : I need to execute/interpret the perl requests away from mod_perl. Can you explain why you want to do this? Your stated requirement is already met by CGI, FastCGI, SpeedyCGI, and a bunch of other things, but we can't really recommend anything specific without more information. - Perrin
Re: Apache::DBI
Paul Simon wrote: I wasn't sure if Apache::DBI was screwing with ORACLE, especially with persistent connections... The Apache::DBI code is really short and easy to read. Basically, it just doesn't close connections when you call disconnect. It also does automatic rollbacks at the end of each request to make sure nothing is left in a bad state, and it pings the db connection each time you ask for one to make sure it's still alive. There's nothing in there that should interfere with the normal workings of DBI. - Perrin
Re: mod_perl invokation valid?
Charlie Smith wrote: Question: Even though I have PERL 5.8 installed, we wish to get mod_perl installed to make use of caching. Currently, a listing of the %ENV hash indicates that we're running mod_perl/1.25. Okay, so you have mod_perl installed and now you want to use it. Take a look at the documentation for the Apache::Registry module that comes with mod_perl. That will help you run your CGI scripts under mod_perl. - Perrin
Re: Sticky pnotes with Apache::Registry
David Kaufman wrote: John Heitmann [EMAIL PROTECTED] wrote ... in fact, i've avoided using pnotes after seeing similar inconsistencies and reading reports of others having them, too. that was a while back, though. I've used pnotes extensively for exactly this sort of thing and have found it to be extremely reliable and always cleaned up. I've never seen this problem before, but it does seem to be related to the directory index somehow. Sorry I can't offer a specific solution. I would suggest checking the code for any other possible sources of leaks, i.e. an unintentional closure that holds onto a copy of the DBI handle. maybe Apache::Session (or CGI::Session) can handle these needs? No, Apache::Session is for storing data between requests, which is exactly the opposite of what he's trying to do. It can't handle storing DBI handles anyway, because Storable can't serialize them. - Perrin
Re: Modules Executed Twice
Explanations and other suggested approaches to handling this problem will be most welcome. My suggestion in the past has been to PerlRequire a startup.pl that does a use on your modules, instead of pulling them in with PerlModule. Of course, if you turn PerlFreshRestart on then this is the intended behavior. - Perrin
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
Re: Fw: OT - Santa uses PERL
Robert Landrum wrote: On Fri, Dec 20, 2002 at 10:35:18AM -0800, Bill Moseley wrote: That sounds a lot like Perrin's story. Didn't he save Christmas one year? I wouldn't go that far. There were actually a lot of warehouse problems that led to disappointed customers, but I don't dwell on that because that wasn't my area. Perhaps Perrin is an elf. :) I'll be an elf if I can jump up onto a horse like Legolas. - Perrin
Re: [OT] mod_proxy, mod_perl, php
Scott Alexander wrote: No mod_perl doesn't serve the documents. I'm just using a PerlTranshandler to change the uri. Okay, that should work then. So if I add php support to the mod_perl server. How much extra load/memory usage strain will it add to the mod_perl server. I don't know; that's a PHP question. If I add a www -management system to our existing intranet application I want that all the www pages are in the www -management system not php pages on the front_end (have to add php support of course) and html pages on the mod_perl server. Sorry, I don't understand what you're talking about here. Or would it be better to have a nfs on the front_end accessible from the mod_perl server. So users can update the documents using the intranet application. Then www requests are handled only by the front end with now added php support. I don't see any good reason not to put PHP on the backend and do all the page generation there. It keeps the front-end simple too. - Perrin
Re: [OT] mod_proxy, mod_perl, php
Scott Alexander wrote: At the moment I have a front_end server with no php support. Backend is mod_perl. I'm planning to extend our document management system to serve www pages. The html documents are on the mod_perl machine. What happens if users add php code to their html documents? Nothing, unless you add PHP support to that machine and make sure mod_perl is not serving those documents. You can't have them both handle the same documents. If I add php support on the front_end will it work normally? No, not if the front-end is proxying. It has to be actually serving those documents locally in order to run them through PHP. - Perrin
Re: [OT] Ideas for limiting form submissions
Bill Moseley wrote: what would you recommend for caching the md5 strings. Cache::Cache or DBM? I suppose a Cache::Cache file cache would be the easiest. In order of speed: IPC::MM BerkeleyDB (with built-in locking) Cache::Mmap Cache::FileBackend (from Cache::Cache -- no need to use Cache::Cache front-end unless you want expiration) IPC::MM is shared memory, so it won't persist data across restarts. - Perrin
Re: Double execution of PerlRequire statement
Kyle Oppenheim wrote: This behavior is documented in the guide... http://perl.apache.org/docs/1.0/guide/config.html#Apache_Restarts_Twice_On_S tart This is true, although technically it shouldn't require the same file twice unless you have PerlFreshRestart on (which is a bad idea). - Perrin
Re: When perl is not quite fast enough
Jeff AA wrote: I have two questions: 1) In this list, I have seen folks asking general Perlish questions told to take their discussions elsewhere, along with the useless recommendation that they browse lists.perl.org - I have done this several times and joined a few of the lists, but only ever found lists that were rather beginner. I have also lurked in some of the groups.yahoo.com pearly lists without finding the right level. - can folks name any specific useful intermediate/advanced Perl lists? i.e. Perl 4+ years in a commercial env In addition to perlmonks.org, the usenet groups and IRC have the highest concentration of experienced Perl coders. I would guess that symbol table fiddles might be risky in a mod_perlish env. No more so than any other place. The biggest risk is that symbol table hacks are usually bizarre and hard to read. The Apache::PerlRun module modifies the symbol table in order to reset globals, and I've done really simple things with it to automatically build accessor methods (which can be better than AUTOLOAD with mod_perl because of memory sharing). - Perrin
Re: AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)
Christopher Grau wrote:
I may be veering off-topic, but I've started doing similar things in my
own code (generating accessor methods via AUTOLOAD). I ended up writing
`Class::Autoload,' which I intend to upload to CPAN when I'm done with
documentation and testing.
Mine was very simple and didn't need to handle any odd cases, which was
why I didn't bother using a CPAN module. I would probably check
Class::MethodMaker before doing it this way again.
I had this in a shared class:
Package Util;
sub build_accessors {
my ($class, $pkg, $attr_names) = @_;
no strict 'refs';
foreach my $attr_name (@{$attr_names}) {
*{$pkg . ::$attr_name} = sub { return $_[0]-{$attr_name}; };
}
}
And then I would put something like this in the classes that needed it:
BEGIN {
my @attr_names;
@attr_names = qw(
foo
bar
baz
);
Util-build_accessors(__PACKAGE__, \@attr_names);
}
- Perrin
Re: SSI Not Working Apache
Martin Kuria wrote: mod_include is not included please do advice what do I need to have ssi to work please do help Hi Martin, This list is not for general Apache configuration questions. Please see http://httpd.apache.org/lists.html to find a more appropriate list to ask your question on. - Perrin
Re: Apache::Session and user sessions
md wrote: My question is with regards to whether I need or should put the submitted data into the session as the user navigates the forms (to create an account). The user will be taken through three forms to create an account. So for instance, form one will ask the user to create a username, password, and provide an email address. Before moving on to form two (billing info), should I put this data in the session, or just go ahead and dump it in the database (after making any nec. checks), since I won't need the info until they actually login? Or should I collect all the info from all three screens by putting it in the session as the user traverses the forms and then put it all in the database at once? I'm currently using the first option. BTW, it is possible for a user to create a free account by hitting form one only, so no harm would come if something happened after form one. This is really a question of requirements. In systems where all information needs to be collected before a valid account can be created, you have to wait until the end to put it in the permanent tables. I usually don't store form input in the session because it leads to strange results if the user has multiple browser windows open on the site, but that may not be an issue for your application. Another question, while not mod_perl related (sorry:), is how to taint check input data like usernames, address fields and email addresses. All info is just put in the database, no unsafe system calls are run. I'm curious as to what characters to limit for usernames in particular. If you're using bind variables with DBI, there is no technical reason to restrict the characters at all. Just make sure you HTML-escape them whenever you display them on a page. - Perrin
Re: Apache::Session and user sessions
Rafiq Ismail (ADMIN) wrote: I'm not sure how often a user will attempt to complete one form through multiple browsers. To be honest I'm not sure that he/she should. There are all kind of forms. An obvious example would be a search. Users often open up multiple windows when browsing a site and do searches in them. If you store search-related data in the session, the multiple windows will interfere with each other. These should be stored in the HTML instead. - Perrin
Re: Resetting cache Apache::Registry
Justin Luster wrote:
I know that when you require or use helper files in a Perl Script,
and you are using Apache::Registry, when changes are made to the helper
files they are not recognized until you restart Apache. In the
documentation it says that you can change the Apache configuration file
to do this for you.
That's a reference to Apache::Reload or Apache::StatINC. You can do
that in an htaccess file if your host allows it.
What I want to know is if there is a way to clear
out the files or code in the Apache::Registry cache via a Perl Script.
Yes, but understand that we're not talking about the Apache::Registry
cache here. A::R just caches your CGI script itself, not the modules.
The modules are cached as a normal function of Perl, i.e. once it has
compiled a module that module stays in memory until the Perl process
shuts down.
To make Perl reload a module, you can do this:
delete $INC{'Your/Module.pm'};
require Your::Module;
But that glosses over a lot of details about imports and such, so you're
better off using Apache::Reload if you can.
- Perrin
Re: General interest question: PDF contents handling in PostgreSQL.
Fabián R. Breschi wrote: I wonder if using ModPerl and PostgreSQL there's any possibility to resemble what in Oracle is called 'Intermedia', in this particular case parsing/indexing content of PDF files inside PostgreSQL as a LOB or alternatively as a flat OS file with metadata parsed/indexed from it into the RDBMS. You can easilly add this to DBIx::FullTextSearch. All you need to do is write a simple frontend that uses a PDF reading module to extract the text. However, it uses MySQL rather than PostgreSQL. - Perrin
Re: [SOT] Strange browser behavior
Nick Challoner wrote: My questions are, is there some IE anomaly or some anomalous way of configuring or using IE that can cause it to all of a sudden do a GET instead of a POST (anything short of manually entering the url)? User bookmarking the page (well, adding to favourites considering we're talking about IE) and then returning to it via the bookmark? It may also no longer send POST data or give the option of no longer sending it if you go back to a page resulting from a POST after a certain amount of time. - Perrin
