Re: cron for mod_perl?
From: Matt Sergeant [EMAIL PROTECTED] On Thu, 15 Feb 2001, Perrin Harkins wrote: Maybe we should add process scheduling into Apache, and a file system, and a window manager, and... Perhaps its the difference between people who've had to write shrink-wrap apps? The question for me is dependencies. We add in Schedule::Cron or whatever and then you've got to add in LWP or HTTP::GHTTP or HTTP::Lite to do the request. Its just something that would be useful to a lot of people, IMHO. I'm not sure why you would want a perl cron-alike under unix unless you are doing something so frequently that you don't want to reload perl for every run, but it would be handy to have a scheduling module that would work on windows NT or Win2k to provide the missing cron functionality. Les Mikesell [EMAIL PROTECTED]
Re: cron for mod_perl?
On Wed, 14 Feb 2001, Perrin Harkins wrote: On Wed, 14 Feb 2001, Pierre Phaneuf wrote: I guess two persons "simpler" aren't always the same: I find it easier laying out a table and querying it than hacking something to fiddle with my crontab safely. As far as I know, crontab -e is perfectly safe. "crontab -l | foo" and "foo | crontab -" are your friends. as for putting cron into Apache: I don't understand why that's wanted in the first place. When connecting to the database outside the httpd it doesn't matter if it goes a little slow. And having separate programs to do the maintenance would easily be much simpler than trying to drop everything into the httpd. All this might of course be way off since it's not really clear to me what the real goal is in the first place. (this thread has been kinda like "I want to use facility Y", instead of ``I want to accomplish X. I thought I might be able to use facility Y. But Y doesn't seem like it's quite right, because of Z. What should I use instead of Y, or how can I overcome Z?''[1] :-) So: What is the task at hand (more than "run something at certain intervals" (which is what cron(8) is for)). - ask [1] http://perl.plover.com/Questions.html -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com
Re: cron for mod_perl?
On Thu, 15 Feb 2001, Ask Bjoern Hansen wrote: On Wed, 14 Feb 2001, Perrin Harkins wrote: On Wed, 14 Feb 2001, Pierre Phaneuf wrote: I guess two persons "simpler" aren't always the same: I find it easier laying out a table and querying it than hacking something to fiddle with my crontab safely. As far as I know, crontab -e is perfectly safe. "crontab -l | foo" and "foo | crontab -" are your friends. as for putting cron into Apache: I don't understand why that's wanted in the first place. When connecting to the database outside the httpd it doesn't matter if it goes a little slow. And having separate programs to do the maintenance would easily be much simpler than trying to drop everything into the httpd. Its just a convenience thing. I've wanted to be able to do this too, for example to have emails go off at a particular interval. So yes, it can be done as cron + URI, but I'm just jealous of AOLServer's ability to do it all in one. This is especially important for a shrink-wrapped type application, where asking people to install a crontab entry is just another pain in the installation process (note that cron might be different on different OS's, and so might the shell be, so this is a real problem for some people - whereas if it were in Apache we'd know the platform). -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: cron for mod_perl?
Ask Bjoern Hansen wrote: So: What is the task at hand (more than "run something at certain intervals" (which is what cron(8) is for)). I am building a web something-something (I don't know what's the current buzzword for that, you know, the big integrated things) similar to the ArsDigita Community System (ah, I bet this helped a lot more! :-) ). My first occurence of this need was about expiring session keys from the database. At first, I was about to do a little query that run from a cleanup handler every so many seconds, but after that, I was stealing some more ideas from ACS (it's a very good idea, but AOLserver and Tcl, ick!), and I was getting jealous of the AOLserver scheduler, which they use abundantly. For example, you can check a list of URLs at regular interval to see if your machines are up (and get a warning if some are not), or you can send warnings to users when their car is about to get towed away because of parking regulations. :-) Anyway, from fussing around in ACS, it came to me that a general scheduler is a pretty good idea, so I set to it. More about the rationale in another reply to Matt Sergeant... [1] http://perl.plover.com/Questions.html Very good one, I almost died of a chocolate-covered banana indigestion. :-) -- "The 3 great virtues of a programmer: laziness, impatience and hubris." -- Larry Wall
Re: cron for mod_perl?
Ask Bjoern Hansen wrote: I guess two persons "simpler" aren't always the same: I find it easier laying out a table and querying it than hacking something to fiddle with my crontab safely. As far as I know, crontab -e is perfectly safe. "crontab -l | foo" and "foo | crontab -" are your friends. Ah yes. The problem with this is between the "crontab -l" and the "crontab -". You have to parse the crontab, find your own entry without disturbing other entries, mix in your new/modified entry, etc... Not that it's impossible, but I don't like this very much and I find INSERT/SELECT/UPDATE easier. Also, I'm not totally sure a piped open would be okay in Apache, since this has a fork() underneath. Probably that it cannot be done in the obvious straightforward way, 'open("crontab -l |")'. I would have to go through the Apache subprocess API and do things I'd rather not be doing (hey, I was the one annoyed by path_info not being translated for me :-) ). Call me lazy. :-) -- "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." -- [EMAIL PROTECTED]
Re: cron for mod_perl?
Matt Sergeant wrote: as for putting cron into Apache: I don't understand why that's wanted in the first place. When connecting to the database outside the httpd it doesn't matter if it goes a little slow. And having separate programs to do the maintenance would easily be much simpler than trying to drop everything into the httpd. Its just a convenience thing. I've wanted to be able to do this too, for example to have emails go off at a particular interval. So yes, it can be done as cron + URI, but I'm just jealous of AOLServer's ability to do it all in one. This is especially important for a shrink-wrapped type application, where asking people to install a crontab entry is just another pain in the installation process (note that cron might be different on different OS's, and so might the shell be, so this is a real problem for some people - whereas if it were in Apache we'd know the platform). Same reasons here for wishing for this. By the way, it could even be done as "cron + perl script that does the job directly (outside of Apache)", but I'm trying to integrate things, so that you start one DBMS daemon and N Apache servers (on different machines, of course), and you have the application running. As you mention, there is also the problem of being cross-platform. Apache and mod_perl runs on Windows, but I would have to make people get themselve a cron for Windows? I think that I *will* make an Apache::Schedule module, but much less ambitious and more closely related to the way Apache and mod_perl do things. What about this summary: Apache::Schedule let you register callbacks (per Apache child process) that will be called after a given amount of time has passed, either once or repeatedly. Callbacks will be called at the next request after the required time, or at child exit time. Would anyone find that useful? Of course, you can always run it from cron. Or make yourself a daemon. Or use POE. Or use Zope. Or (even) use AOLserver. TMTOWTDI. Is there a mod_perl for AOLserver? ;-) -- "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn
Re: cron for mod_perl?
On Thu, 15 Feb 2001, Pierre Phaneuf wrote: Ask Bjoern Hansen wrote: I guess two persons "simpler" aren't always the same: I find it easier laying out a table and querying it than hacking something to fiddle with my crontab safely. As far as I know, crontab -e is perfectly safe. "crontab -l | foo" and "foo | crontab -" are your friends. Ah yes. The problem with this is between the "crontab -l" and the "crontab -". You have to parse the crontab, find your own entry without disturbing other entries, mix in your new/modified entry, etc... Not that it's impossible, but I don't like this very much and I find INSERT/SELECT/UPDATE easier. I might be barking at the wrong tree, but why cron? Why don't you use at(1). you don't need to parse crontab for that, and you can spawn processes with whatever intervals on demand. basically you can call at(1) itself at the end of at() so you can do the same as crontab. See http://man.he.net/man1/at (I don't seem to find the manpage for at(1) on Mandrake box :( _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cron for mod_perl?
On Thu, Feb 15, 2001 at 09:04:43AM -0500, Pierre Phaneuf wrote: Apache::Schedule let you register callbacks (per Apache child process) that will be called after a given amount of time has passed, either once or repeatedly. Callbacks will be called at the next request after the required time, or at child exit time. Would it work even if the server is not getting any requests? And if so, how? Tim.
Re: cron for mod_perl?
Stas Bekman wrote: I might be barking at the wrong tree, but why cron? Why don't you use at(1). you don't need to parse crontab for that, and you can spawn processes with whatever intervals on demand. basically you can call at(1) itself at the end of at() so you can do the same as crontab. Yes, at is much better suited, but you still have the problem of forking under Apache (possible, but hairy) and systems where there is no at. -- "The camel has not evolved to smell good. Neither has Perl." -- Larry Wall
Re: cron for mod_perl?
Tim Bunce wrote: Apache::Schedule let you register callbacks (per Apache child process) that will be called after a given amount of time has passed, either once or repeatedly. Callbacks will be called at the next request after the required time, or at child exit time. Would it work even if the server is not getting any requests? And if so, how? No, that's the problem. :-) That's where my idea of a cron job that does a HEAD request on an URL that has the cleanup handler installed every 30 minutes (say) comes from, so that there is a minimum level of service. But while I would mention that in the README, that is outside the scope of the perl module to do and left to the individual user. The restriction would be clearly documented, and here's a way to help out with it, but if it doesn't do what you want, don't use it (or tell us how to improve it). AOLserver has it easy, being in a single process and having this scheduler tied in at the select() level, it never misses a beat and is always on time (to a few tens or hundreds of milliseconds, if the server is not overloaded). Apache is more complicated, with multiple child processes that die after a while and don't know about each other (and cannot depend on one particular child process to be there) and so on. You could put something in the Apache parent process, but that would require a new hook in Apache itself. That would be cool, but still not free of problems: - the parent process often runs with root privileges, do we run the scheduled callback as root inside the parent process? - if we do, if it is long running, you could have problems with Apache Maybe it could register an URL to invoke on itself? Anyway, I'm not enough into Apache to do something like *that*, even though I'd love to... -- "I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-)" -- Linus Torvalds
Re: cron for mod_perl?
"PP" == Pierre Phaneuf [EMAIL PROTECTED] writes: As far as I know, crontab -e is perfectly safe. "crontab -l | foo" and "foo | crontab -" are your friends. PP Ah yes. The problem with this is between the "crontab -l" and the PP "crontab -". You have to parse the crontab, find your own entry without Very limited thinking going on here. The crontab program honors the EDITOR environment variable. Now... setenv EDITOR=myscript then run crontab -e. Poof. Atomic update. With appropriate Perl modules for the cron files, this should be trivial. But then, you probably aren't doing this from mod_perl...
Re: cron for mod_perl?
On Thu, 15 Feb 2001, Stas Bekman wrote: I might be barking at the wrong tree, but why cron? Why don't you use at(1). And there's a CPAN module for it: Schedule::At. It claims to be cross-platform, and I believe NT has a version of at(1). - Perrin
Re: cron for mod_perl?
Vivek Khera wrote: PP Ah yes. The problem with this is between the "crontab -l" and the PP "crontab -". You have to parse the crontab, find your own entry without Very limited thinking going on here. The crontab program honors the EDITOR environment variable. Now... setenv EDITOR=myscript then run crontab -e. Poof. Atomic update. That's what I intended to do (that's why I didn't mention concurrency problems), but you still have to fork, which is hairy under mod_perl. With appropriate Perl modules for the cron files, this should be trivial. But then, you probably aren't doing this from mod_perl... Well, yes, why? :-) -- "I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-)" -- Linus Torvalds
Re: cron for mod_perl?
On Thu, 15 Feb 2001, Matt Sergeant wrote: Its just a convenience thing. I've wanted to be able to do this too, for example to have emails go off at a particular interval. So yes, it can be done as cron + URI, but I'm just jealous of AOLServer's ability to do it all in one. This is especially important for a shrink-wrapped type application, where asking people to install a crontab entry is just another pain in the installation process (note that cron might be different on different OS's, and so might the shell be, so this is a real problem for some people - whereas if it were in Apache we'd know the platform). Maybe we should add process scheduling into Apache, and a file system, and a window manager, and... Okay, I'm being silly, and there are times when duplication is necessary, but cron is such a well-established way of solving this problem that anything else sounds strange. The original post didn't say that the goal was to modify the scheduled jobs dynamically from mod_perl, and that does add a new wrinkle. I still think a good Perl interface to cron would be more obvious and more reliable. - Perrin
Re: cron for mod_perl?
"PP" == Pierre Phaneuf [EMAIL PROTECTED] writes: With appropriate Perl modules for the cron files, this should be trivial. But then, you probably aren't doing this from mod_perl... PP Well, yes, why? :-) You really want to have your web server writing files that execute arbitrary programs at arbitrary times? Sounds risky.
Re: cron for mod_perl?
On Thu, 15 Feb 2001, Perrin Harkins wrote: Maybe we should add process scheduling into Apache, and a file system, and a window manager, and... :-) Okay, I'm being silly, and there are times when duplication is necessary, but cron is such a well-established way of solving this problem that anything else sounds strange. The original post didn't say that the goal was to modify the scheduled jobs dynamically from mod_perl, and that does add a new wrinkle. I still think a good Perl interface to cron would be more obvious and more reliable. Perhaps its the difference between people who've had to write shrink-wrap apps? The question for me is dependencies. We add in Schedule::Cron or whatever and then you've got to add in LWP or HTTP::GHTTP or HTTP::Lite to do the request. Its just something that would be useful to a lot of people, IMHO. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: cron for mod_perl?
Perrin Harkins wrote: The original post didn't say that the goal was to modify the scheduled jobs dynamically from mod_perl, and that does add a new wrinkle. I still think a good Perl interface to cron would be more obvious and more reliable. Sorry, maybe I didn't make that quite clear. Yes, it is a goal. For example, to take an example from the ACS, a user can add or remove parking warnings from the web site. I could write a file somewhere and have another process in cron process that file every once in a while, but I would like direct and immediate feedback/effect. This could be simply an Apache::Cron module or something like that, to ease the task of add/modifying/removing cron jobs from mod_perl, I agree. -- "As usual, this being a 1.3.x release, I haven't even compiled this kernel yet. So if it works, you should be doubly impressed." -- Linus Torvalds
Re: cron for mod_perl?
Vivek Khera wrote: With appropriate Perl modules for the cron files, this should be trivial. But then, you probably aren't doing this from mod_perl... PP Well, yes, why? :-) You really want to have your web server writing files that execute arbitrary programs at arbitrary times? Sounds risky. Well, I'd like to keep this as little arbitrary that I can. For examples of what I'd like to be able to do: http://tz.arsdigita.com/ http://remindme.arsdigita.com/ http://uptime.arsdigita.com/uptime/ The last one fetches URLs from the web. As for risky: this is just as risky as using mod_perl at all. What is run is controlled by the script, so it's not 100% arbitrary, if you can help it. If it was inside Apache, then it wouldn't be arbitrary programs, it would restricted to the server. -- "You can have my Unix system when you pry it from my cold, dead fingers." -- Cal Keegan
Re: cron for mod_perl?
Perrin Harkins wrote: Well, if I call the "check for things to do" URI every minute, then I'll be just fine. Many times, I'll just check and find nothing to do Huh? Why would you call it if there's nothing to do? Are you thinking you'll write a cron-ish task/timing spec for your Perl app and just use the cron triggers as a constant clock? Yes, exactly. My plan is to have a table with the tasks in my database, and check expired tasks in a cleanup handler. I'll have to lock the table, so that only one process does that. I'll also query the database only every so often, not at every request cleanup. The more hits I get, the more accurate the "cron" will be, but I think I will use a cron trigger a request to have a minimum level of accuracy (could be every half-hour, just to make sure we're never late by more than that, or whatever is appropriate). Anything better? -- "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman
Re: cron for mod_perl?
Huh? Why would you call it if there's nothing to do? Are you thinking you'll write a cron-ish task/timing spec for your Perl app and just use the cron triggers as a constant clock? Yes, exactly. My plan is to have a table with the tasks in my database, and check expired tasks in a cleanup handler. I'll have to lock the table, so that only one process does that. I'll also query the database only every so often, not at every request cleanup. The more hits I get, the more accurate the "cron" will be, but I think I will use a cron trigger a request to have a minimum level of accuracy (could be every half-hour, just to make sure we're never late by more than that, or whatever is appropriate). Anything better? Well, by frequently hitting your web server and having it look in the database to decide to do nothing, you're putting a lot of unnecessary stress on your server. What's wrong with making individual cron jobs that call individual URLs (think of it as RPC) to cause actions on your web server exactly when you want them done? Doesn't that sound a whole lot simpler? - Perrin
Re: cron for mod_perl?
Perrin Harkins wrote: Yes, exactly. My plan is to have a table with the tasks in my database, and check expired tasks in a cleanup handler. I'll have to lock the table, so that only one process does that. I'll also query the database only every so often, not at every request cleanup. Well, by frequently hitting your web server and having it look in the database to decide to do nothing, you're putting a lot of unnecessary stress on your server. What's wrong with making individual cron jobs that call individual URLs (think of it as RPC) to cause actions on your web server exactly when you want them done? Doesn't that sound a whole lot simpler? I think you are over-evalutating the stress on my server. With the speediest time base I was talking about (once per minute cron job), that would be 1440 HEAD requests per day, each requiring 1 simple database query that will most probably return no row at all (a query that returns many rows is slower, because it has to transmit these rows). Many sites with database-driven pages have multiple complex queries on some pages and run in the millions of page-views per day. As for the simplicity, having multiple individual custom cron jobs is simpler than one single generic cron job? But still, I don't like my solution very much either. My problem lies in the case where I get a lot of hits, I want to be careful of what I run in my cleanup handler (if I hit the database at every cleanup, I'll start piling up daemons if I get plenty of hits). I was thinking of having a variable with a timestamp of when we last checked the database, and getting into a cleanup handler, we'd hit the database only if it was more than a minute ago that we checked. -- Implementation: n., the fruitless struggle by the talented and underpaid to fulfill promises made by the rich and ignorant.
Re: cron for mod_perl?
Perrin Harkins wrote: Sure, but why waste resources? Because it's easy? :-) As for the simplicity, having multiple individual custom cron jobs is simpler than one single generic cron job? Yes, much simpler, at least for the scheduling and dispatching part. Instead of designing database tables to hold timing info on jobs and code to check it that is smart enough to remember when it last ran and prevent race conditions, you can write a simple crontab with one call to wget per job. The actual implementation of the jobs is pretty much identical either way. I guess two persons "simpler" aren't always the same: I find it easier laying out a table and querying it than hacking something to fiddle with my crontab safely. Do it whatever way suits you. I'm just suggesting that you try the lazy way if possible. I could mash the two together: have a single URL trigger that looks up the tasks to do in a database, but have it schedule it's next run itself using "at". Whew, there *is* a whole lot more than one way to do it! :-) I was thinking of having a variable with a timestamp of when we last checked the database That will have to be some sort of shared memory or file-based thing, since you won't be using the same process each time. I was intending on being lazy and let a bunch of processes find out there is nothing to do because one of them already did the work. ;-) Ahh, the joy of wasting resources... Would anyone be interested in seeing an Apache::Schedule, with an API similar to the Tcl API in AOLserver? http://aolserver.com/docs/tcldev/tapi-114.htm http://aolserver.com/docs/tcldev/tapi-113.htm http://aolserver.com/docs/tcldev/tapi-115.htm -- "We make rope." -- Rob Gingell on Sun Microsystem's new virtual memory.
Re: cron for mod_perl?
On Wed, 14 Feb 2001, Pierre Phaneuf wrote: I guess two persons "simpler" aren't always the same: I find it easier laying out a table and querying it than hacking something to fiddle with my crontab safely. As far as I know, crontab -e is perfectly safe. - Perrin
Re: cron for mod_perl?
Perhaps I've missed something, but in all this discussion no one has asked what it is you're trying to do. All I know is that you want to schedule something in a database and then check that database every minute (or so) and process the scheduled somethings. Generally speaking, 'at' is the simplest alternative. I've used 'at' in similar circumstances (though never from the web). However, this does not meet your needs of using a cached database connection. Another possibility is to write a daemon yourself and use some type of IPC or RPC to schedule events to that daemon. As the daemon runs, it just forks off and processes the scheduled jobs as those times pass. This requires some crafty work with sig alarm or other mechanism. I once remember seeing an alarm lib somewhere that would allow you to set more than one alarm. Without knowing what it is you're trying to implement, I think we've just about exhausted the possibilities for a scheduler within mod_perl/apache. Robert Landrum -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: cron for mod_perl?
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: Is there a way to have a Perl function called at some point in time, like I think AOLserver can do in Tcl (but I don't want to do either AOLserver or Tcl!)? I thought about checking the time in a PerlCleanupHandler, but this would be in each Apache subprocess and I want this to get called only once. The precision is not so important (unless we're talking hours later or something like that!). I thought of having a table of jobs in my PostgreSQL database and (carefully avoiding race conditions with transactions/locking) checking if the next job was due to be run, but that doesn't "smell" very good. I could run the query only on the condition that a minute has passed since the last time we did it, but still, I'm not sure. I would like to know if anyone already did that or have any idea on how to do that more properly? Pretty much what you've already found out - Apache has no "cron" like daemon. One way you can do it is fork off a sub-process and run some sort of Cron perl module (I think there's a Cron module on CPAN, or you can run cron-like features with POE). -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: cron for mod_perl?
"PP" == Pierre Phaneuf [EMAIL PROTECTED] writes: PP Is there a way to have a Perl function called at some point in time, PP like I think AOLserver can do in Tcl (but I don't want to do either PP AOLserver or Tcl!)? Set up a handler and have a cron job "GET" the URL for it. You already have the "GET" program from the lwp package while installing mod_perl.
Re: cron for mod_perl?
Is there a way to have a Perl function called at some point in time, like I think AOLserver can do in Tcl (but I don't want to do either AOLserver or Tcl!)? I thought about checking the time in a PerlCleanupHandler, but this would be in each Apache subprocess and I want this to get called only once. The precision is not so important (unless we're talking hours later or something like that!). Matt Sergeant wrote: Pretty much what you've already found out - Apache has no "cron" like daemon. One way you can do it is fork off a sub-process and run some sort of Cron perl module (I think there's a Cron module on CPAN, or you can run cron-like features with POE). Hmm, too bad, that would have been easy to implement in the Apache core request processing loop (it's build into the core of AOLserver). I'll look to make sure, but I think this will be possible in Apache 2.0. Anyway, that doesn't fix my problem for now. Isn't forking off from Apache rather nasty? I saw something to that effect somewhere in the eagle book and on some web pages, but I think there are ways to do that without causing problems. Perrin Harkins wrote: The common way to do it is to just use the real cron facility (assuming you are on unix) and have it call a URL on your server using LWP. I am on a Unix-like system, but I wanted the events to be updated by the web server itself, so that I could use the Apache::DBI cached connection to the DBMS (I want to store the events in there). This seems good, exposing a URL that a cron job would fetch every minute (or something like that). I don't like much the idea of exposing an URL like that (could be used to cause a DoS, accessing the DBMS like crazy, but I guess this is a problem for any database-driven web site), but I can always restrict the URL to 127.0.0.1... Vivek Khera wrote: Set up a handler and have a cron job "GET" the URL for it. Yeah, I think that's what I'll do! You already have the "GET" program from the lwp package while installing mod_perl. I have the mod_perl RPM that comes with Red Hat, and I can't find the LWP anywhere. Not that I can't install it or use wget instead... Thanks everyone! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: cron for mod_perl?
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: Matt Sergeant wrote: Pretty much what you've already found out - Apache has no "cron" like daemon. One way you can do it is fork off a sub-process and run some sort of Cron perl module (I think there's a Cron module on CPAN, or you can run cron-like features with POE). Hmm, too bad, that would have been easy to implement in the Apache core request processing loop (it's build into the core of AOLserver). I'll look to make sure, but I think this will be possible in Apache 2.0. Anyway, that doesn't fix my problem for now. Isn't forking off from Apache rather nasty? I saw something to that effect somewhere in the eagle book and on some web pages, but I think there are ways to do that without causing problems. Yes, its a pain. I suggest using the ways detailed below. My only problem with those ways is that its not controlled from your application generally, unless you write your own cron-a-like in Perl, and access your datastore to get the configuration. Perrin Harkins wrote: The common way to do it is to just use the real cron facility (assuming you are on unix) and have it call a URL on your server using LWP. I am on a Unix-like system, but I wanted the events to be updated by the web server itself, so that I could use the Apache::DBI cached connection to the DBMS (I want to store the events in there). The cached connection will be used, just as it would for the rest of your application. Also note that HTTP::GHTTP loads a *lot* faster than LWP, and executes faster too. And yes, you can restrict that URL to localhost, or password protected. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: cron for mod_perl?
Matt Sergeant wrote: Isn't forking off from Apache rather nasty? I saw something to that effect somewhere in the eagle book and on some web pages, but I think there are ways to do that without causing problems. Yes, its a pain. I suggest using the ways detailed below. My only problem with those ways is that its not controlled from your application generally, unless you write your own cron-a-like in Perl, and access your datastore to get the configuration. Well, if I call the "check for things to do" URI every minute, then I'll be just fine. Many times, I'll just check and find nothing to do, but it'll be under "enough" application control. You might contrieve adding a cron entry as being "outside the application" though... I would really like putting this in a cleanup handler, but the problem I see is if I don't get any hit for too long (which might happen for an internal web site, say over the weekend), I might miss events. I'll probably have a combination of both approaches... I am on a Unix-like system, but I wanted the events to be updated by the web server itself, so that I could use the Apache::DBI cached connection to the DBMS (I want to store the events in there). The cached connection will be used, just as it would for the rest of your application. Also note that HTTP::GHTTP loads a *lot* faster than LWP, and executes faster too. And yes, you can restrict that URL to localhost, or password protected. I was thinking of using wget with "-O /dev/null". :-) As for the cached database connection, I knew about that, but I was thinking of the forking approach (where there was no cached connection available (not that it couldn't be cached!)). -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: cron for mod_perl?
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: Well, if I call the "check for things to do" URI every minute, then I'll be just fine. Many times, I'll just check and find nothing to do Huh? Why would you call it if there's nothing to do? Are you thinking you'll write a cron-ish task/timing spec for your Perl app and just use the cron triggers as a constant clock? - Perrin