Yukio has asked for the wisdom of the Perl Monks concerning the following question:

Oh merciful monks, help a brother in his time of need.

I am having to rewrite an application because of third party requirements that I cannot change and on a hosting solution that is being far from helpful. The basic problem is that:

  1. I have to query a database for the least recent record (fifo) and assemble a HTTP request based on it -- BUT I can't send more than one request within a given interval (right now, that's three minutes).
  2. I have to figure out how to address this problem without using server-side triggers (CHRONTAB, etc.) and without being able to create a persistent process (my bet is that the system admin will happily reap this process assuming it was zombie).
  3. I also have to be able to trigger this only through an HTTP request (ie. the *only* access I have to the machine is via FTP and HTTP).
At present, the only thing I can think to do (aside from moving to a _good_ hosting solution) is trigger the script remotely using a minimized webpage on one of the office computers and refresh it every minute. The script it calls would watch for any processes that hadn't finished within the previous three minutes and either shut down or continue based on what it finds. This has its problems because it's always possible for the window to be closed accidentally. I'm sure there are other problems with this 'solution' that I don't see yet.

This is running on a Unix box (a flavour of BSD).

Does anyone have any helpful advice or warnings?

(Sometimes I love my job and, actually, this is one of those times.)

Replies are listed 'Best First'.
Re: Scheduling tasks the _hard_ way
by Hero Zzyzzx (Curate) on Oct 17, 2001 at 00:20 UTC

    Does the HTTP output have to originate from the server with the draconian access restrictions?

    Is the remote machine totally firewalled off? I know for mySQL (and most other databases) you can easily connect to the DB remotely, (for mySQL it's port 3306) meaning you can run the script on another machine with a crontab entry, and just connect/disconnect to the remote DB in the specified time period.

    Another option- write your script on the remote machine to just report the results of the query, either in some XML format or pipe-delimited, and then ding that script periodically and parse the info out with LWP::Simple and split().

    Here's an article from my personal site that does something similar to what I'm talking about above.

    Good luck!

    -Any sufficiently advanced technology is
    indistinguishable from doubletalk.

[reply]
      Thanks for your fast reply.

      Unfortunately, we don't have much of a choice in the server solution we're using. As much as I'd like to set up a dedicated host of my own, we don't have the skills in-house to maintain a secure server. Also, this project involves an ecommerce component, so I need to keep it as localized as possible -- including this script.

      Also, this problem has nothing to do with firewalls or even security, believe it or not. I'm sure I could actually manage to wangle the server into doing what I want, or intentionally spin off a zombie or two to manage the task of keeping the process going. Unfortunately, the host would probably start killing off the processes as soon as it saw them. The host just doesn't want its clients messing with its machines -- so no terminal access and no scheduled tasks. I won't name the company, but it is fairly big and well-known. It just doesn't trust its clients.

      Thanks for the suggestions, though.

      I hope someone else has some equally helpful suggestions.

[reply]
Re: Scheduling tasks the _hard_ way
by perrin (Chancellor) on Oct 17, 2001 at 01:11 UTC
    What about having your script set an 'at' job that will run it again in 1 minute (or whatever)? Or, if you have to trigger it via HTTP from your office at least use the scheduling on your office computer to run a script that sends the HTTP message. Relying on a web browser to stay up and keep refreshing a page is crazy.
[reply]
      The 'at' is an excellent suggestion. It will mean though I will have to write a VBScript or WScript program to emulate a browser hitting the secure server (and I'm not even sure they can initiate HTTPS connections). I'll start looking in to that. It's a great idea. I also agree with you that depending on a webpage is crazy. It's unfortunately a sign of my desperation.
[reply]
        I'm sure VB can load a web page, but Perl can too. You could install perl on that office machine and use LWP to do the HTTPS request. It may be harder to get SSL working that way though, than to simply use the VB stuff (which I think runs the IE code to do it).
[reply]

Back to Seekers of Perl Wisdom