[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 649
  • Last Modified:

Never-ending While Loop

So I am writing a mail-import script that will run every minute and check for new email messages from an internal IMAP/POP server... The script will run in multiple instances, one per installation and essentially never be 'done' fetching... at any given time there could be 6-7 installations running at one time (maybe more)

I have part of the script already done, accessing IMAP folders and pulling out vars/header info from mailbox was super easy. Only if a new mID exists (unread) does it proceed with any additional functions; making the majority of the seeks to EXIM fairly light weight. I would really like to stay in PHP (vs Perl) because I have a lot of functions ready-to-go from other post-processes I can call and take advantage of easily.

Here is my question....

a) The below article suggests using sleep() in a never end while() loop and running it as a background process. This was my first thought, essentially I can 'never close' the servers IMAP connection and just keep requesting changes from the mailbox, essentially forcing the connection to stay open in while( ....dothis.. sleep(60) ) and just kick the process once for each installation. I've been reading up on background processing PHP in this situation (never-ending); i've done it with perl/bash but I'm not sure how it would work in PHP; if the PHP timeout limit is reached the script will end, correct? or is this just a function of http PHP processing?

(The suggestion to set PHP limits to '0' unlimited timeout is just not something I'm willing to do, to risky) does that blow this concept for me?

http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/PHP_Databases/Q_22132759.html

b) I could set a cron to go off every minute open/close the IMAP connection each time, set it on a cron (per installation) and kick it every minute but that will run the risk of some processes not ending, before the next begins and essentially run the risk of crashing the server all together, if they piled up.

I'd rather go with theory A but i'm a little unsure and dont want to start one direction only to end in defeat..... So?

Can you while(true){ ..dothis.. sleep() } from shell, without modifying the PHP timeouts. essentially forcing sysadmin to kill the PID to stop the process? Would this have any additional effect server side that would make either or both of these inefficient?
0
edjent
Asked:
edjent
1 Solution
 
edjentAuthor Commented:
Oh Yeah! Thanks for any help that gets me moving down the road!
0
 
ropennerCommented:
for B)  you can avoid crashes if you check within your PHP script first whether the previous one finished ... by looking through the current processes 'ps' or another method of detecting that it finished up previously.  Thus avoiding opening up IMAP folders if still in use.  If the previous one didn't finish then exit the script and wait for the next minute to come around.

A)  I've just tried this and it looks like it works with sleeps without having to touch the timeout.  Writing a log file would be advisable so that you can see what is happening as it sleeps and wakes.

The code I just tried sets the timeout to 2 seconds and then sleeps every second for 10 seconds ... the process is not interrupted from the commandline

<?PHP
set_time_limit(2);

$loop =0;
while(1) {
      $loop++;
      sleep(1);
      print "yo  ";
      if ($loop > 10) {
            exit(1);
      }
}
?>
0
 
rubeneCommented:
Maybe you could run your php script as a daemon, because php has wrappers around the common C functions related to daemon processes.

So you could fork child processes from your main php script process and control the child processes from that main process. See: http://php.net/manual/en/function.pcntl-fork.php for info on the pcntl_fork function.Just a suggestion.

If you end up going this way don't forget to use the 'normal' daemon stuff, such as fclosing or redirecting stdin, stdout en stderr to /dev/null.

HTH.
Ruben.
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now