Hi jsia, If your script is consuming the queue as you expect when you run it from a web page or console, then great, the only thing you should need from console is: php -q filename.php &
You could also try "php -q filename.php > beanstalkWorker.log 2>&1 &" to run in the background and redirect any output from the worker to a log file. Note the "-q" flag after the php command in both cases. Hope this helps! --Avi On Jan 1, 1:16 am, jsia <[email protected]> wrote: > I tired to run thephpconsumer in the background but it won't work > > I tired running it in thephpcliphp<scriptsource> & > > the script has a while (1) loop , I tired running itphp > <scriptsource> not running from the background and it works fine but > when i try to run it in the background it won't work. I also added the > set_time_limit(0) in thephpscript. > > Please Advice > > On Dec 4 2008, 7:07 am, avip <[email protected]> wrote: > > > Hi Ludo, > > > That's what I was suspecting, that peek-ready blocks without the aid > > of a while loop on the server, which eases the burden onPHP. I'll try > > it out tonight, thanks for your input :) > > > Cheers! > > --Avi > > > On Dec 3, 5:50 pm, "Ludovic Levesque" <[email protected]> wrote: > > > > On Wed, Dec 3, 2008 at 9:49 PM, avip <[email protected]> wrote: > > > > > Hi Tim, > > > > > I was wondering if you could post some example consumer/worker code > > > > using your class? > > > > > I've managed to daemonize aphpworker script but inevitably there's a > > > > polling while(1) loop somewhere attempting to reserve() a job. This > > > > works fine when there are actually jobs on the queue, but for an empty > > > > queue cpu-usage shoots up to 99%. > > > > > To test out whether or not this is a task or invocation issue, I tried > > > > replacing the job reservation/worker code with a simple print > > > > statement. The result was a well-behavedbackgroundworker. When I > > > > switched back to trying to reserve and delete a job, cpu-usage shot > > > > back up on an empty queue. > > > > > Which obviously leads me to suspect there's some other loop somewhere > > > > in the class responsible for reading or blocking or...not sure > > > > what...that's causing this. > > > > Hi, > > > > I ran into same problems at the beginning. Then I switched to > > > sequential peek method: > > > > $beanstalk = BeanStalk::open( > > > array( > > > 'servers' => array( > > > '192.168.1.40:11300', > > > ), > > > 'select' => 'sequential peek', > > > 'peek_usleep' => 2500, // 2.5 ms > > > ) > > > ); > > > > and no 100% CPU problem now. > > > > Hope it helps, > > > Ludo > > > > > If you could shed some light on this? > > > > > Thanks very much! > > > > --Avi > > > > > On Nov 9, 3:56 pm, avip <[email protected]> wrote: > > > >> Hi yet again! > > > > >> Scratch the last post. I spent more time experimenting with a telnet > > > >> session and reading the protocol itself more carefully. > > > > >> For any other people who are completely new to beanstalkd and are like > > > >> me - wanting to go from installing server to writing code - take note: > > > >> the "use <tube>" command is *just* for producers. Attempting to > > > >> "switch tubes" using "use <tube>" and then reserve will not work and > > > >> actually block if the default tube is empty, not to mention confuse > > > >> you like it did me. The command you're actually looking for when you > > > >> wish to *consume* jobs is "watch <tube>" > > > > >> Very important-and much farther down the protocol doc-is the > > > >> following: > > > > >> The "watch" command adds the named tube to the watch list for the > > > >> current > > > >> connection. A reserve command will take a job from any of the tubes in > > > >> the > > > >> watch list. For each new connection, the watch list initially consists > > > >> of one > > > >> tube, named "default". > > > > >> Take my code from above as example, seems like it should work because > > > >> it's almost straight from the example. My first mistake was assuming > > > >> that. I ran the example first, it worked fine without any error, but > > > >> running it several times in a row after my own code failed, I noticed > > > >> it was erratically timing out. When it wasn't timing out, it behaves > > > >> the way I described in the post prior to this one, just silently > > > >> returns with no actual action taking place. > > > > >> Both the example or the example code above will timeout not because of > > > >> anyPHP-specific error but because doing "use_tube('test2')" doesn't > > > >> actually *switch* tubes in order for you to consume from that job- > > > >> queue - that is managed by the daemon for you provided you tell it you > > > >> wish to *watch* that tube. Not the most obvious thing to realise upon > > > >> initial inspection! > > > > >> So, in the above piece of code I pasted, reserve() is actually trying > > > >> to ask for a job from the tube "default" (created automatically), > > > >> since it is empty (because in a previous piece of code I, correctly, > > > >> used "use_tube('test2')" to add jobs), the function just blocks...in > > > >> other words, the would-be consumer waits for a job; however,PHPtimes > > > >> out the script based on its own timer. > > > > >> If you wish to consume jobs usingPHPscripts in thebackground > > > >> elsewhere without this time limit simply add "set_time_limit(0)" to > > > >> the top of the relevantPHPscript to allow for infinite time - this > > > >> will allow your consumer scripts to run in thebackgroundindefinitely > > > >> until there is a job to be done. > > > > >> Anyway, using "watch" fixes the problem for me, I hope this post saves > > > >> someone a few hours of confusion. > > > >> Tim, if you could correct me on anything I got wrong... :) > > > > >> Thanks! > > > >> --Avi > > > >> On Nov 8, 12:30 pm, avip <[email protected]> wrote: > > > > >> > Hi again Tim, > > > > >> > Running into some basic problems: I have a script that loads the > > > >> > queue > > > >> > with some jobs using put(), this works fine and is verified manually > > > >> > via telnet. In a different script, I attempt to reserve a job using: > > > > >> > <code> > > > >> > require('bin/Others/BeanStalk.class.php'); > > > > >> > $beanstalk = BeanStalk::open(array('servers' => > > > >> > array('127.0.0.1:11300'),'select' => 'random wait')); > > > > >> > $beanstalk->use_tube('test2'); > > > > >> > $job = $beanstalk->reserve(); > > > >> > echo "job=".print_r($job,true); > > > > >> > BeanStalk::delete($job); > > > >> > </code> > > > > >> > Almost straight out of the example, only difference is that put() and > > > >> > reserve() are spread out across two files. I've tried every select > > > >> > mode as well with similar results. > > > > >> > BeanStalk::__call(use_tube) > > > >> > BeanStalk::_do_my_server > > > >> > BeanStalk::reserve > > > >> > BeanQueue::reserve > > > >> > Fatal error: Maximum execution time of 30 seconds exceeded in /bin/ > > > >> > Others/BeanStalk.class.phpon line 989 > > > > >> > Since I added some echos to original, my line 989 is: $data = > > > >> > @fread($this->socket,$in_buf_size); > > > > >> > Is this related to the problems from yesterday? Also, you mentioned > > > >> > v1.1 will be released soon, could you be more specific? (weeks? > > > >> > months?) I'm just trying to figure out whether or not I should try > > > >> > the > > > >> > python or other libs for now. > > > > >> > Thanks! > > > >> > --Avi > > > >> > On Nov 7, 4:33 pm, avip <[email protected]> wrote: > > > > >> > > Ah! Of all the functions, I choose this one to test first with :) > > > > >> > > Will avoid the peek modes until next version, as suggested. > > > > >> > > Thanks again! > > > >> > > --Avi > > > > >> > > On Nov 7, 4:15 pm, "Tim Gunter" <[email protected]> wrote: > > > > >> > > > Hey, > > > > >> > > > Yeah this is an issue with beanstalk clients like mine, and > > > >> > > > beanstalkd > > > >> > > > 1.0. I was trying to implement a polling check that could pull > > > >> > > > the > > > >> > > > next ready job from a pool, but peek() didn't turn out to work > > > >> > > > as I > > > >> > > > initially expected. > > > > >> > > > Avoid the peek modes for now. Stick to 'sequential wait' and > > > >> > > > 'random > > > >> > > > wait' select values. > > > > >> > > > I will release v1.1 of my client shortly, and then the peek > > > >> > > > modes will > > > >> > > > work again, as expected. > > > > >> > > > On Fri, Nov 7, 2008 at 4:11 PM, avip <[email protected]> > > > >> > > > wrote: > > > > >> > > > > Hi, > > > > >> > > > > Wow, that was a fast turn-around! I thought it would take days > > > >> > > > > :) > > > >> > > > > Thanks for both explanations, now that I read them (and after > > > >> > > > > poking > > > >> > > > > in the code for a while), it seems pretty "obviously > > > >> > > > > necessary" to > > > >> > > > > tell the function which server to perform the peek on given > > > >> > > > > there's a > > > >> > > > > pool. > > > > >> > > > > I've been trying some very basicPHPscripts to learn the > > > >> > > > > internals, I > > > >> > > > > have one script that puts a job onto the server (I manually > > > >> > > > > verify > > > >> > > > > it's there with a telnet session). Then the following: > > > >> > > > > <code> > > > >> > > > > require('bin/Others/BeanStalk.class.php'); > > > >> > > > > $beanstalk = BeanStalk::open(array('servers' => > > > >> > > > > array('127.0.0.1:11300'),'select' => 'random peek')); > > > > >> > > > > $beanstalk->use_tube('test'); > > > > >> > > > > $nextJob = ''; > > > >> > > > > $ret = $beanstalk->peek_ready('127.0.0.1:11300',$nextJob); > > > > >> > > > > if ($ret === 1) > > > >> > > > > { > > > >> > > > > echo 'PEEK OPERATION OK<br/>'; > > > >> > > > > echo 'Next ready job='.$nextJob.'<br/>'; > > > >> > > > > } > > > >> > > > > else { > > > >> > > > > echo 'PEEK OPERATION FAILED<br/>'; > > > >> > > > > } > > > >> > > > > </code> > > > > >> > > > > I also turned debugging on and some simple debugging echos to > > > >> > > > > peek_ready(). Result: > > > > >> > > > > Normal output from "if (BeanStalk::DEBUG) echo > > > >> > > > > __METHOD__."\n";": > > > >> > > > > ---------------------------------------------------------------------------------------------------- > > > >> > > > > BeanStalk::__call(use_tube) > > > >> > > > > BeanStalk::_do_my_server > > > >> > > > > BeanQueue::use_tube > > > >> > > > > BeanStalk::__call(peek_ready) > > ... > > read more ยป --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
