3

I did something wrong with my Beanstalkd setup. I have created a producer, but it keeps loading, like an infinite loop. I also posted this issue to GitHub.

I tried adding 2 tubes which have a simple array in them, but the other issue that I encounter is that when I used the name of the tube it doesn’t have the value I expect: it always gets the value on the old tube.

<?php 
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
require("vendor/autoload.php");
function p($s){
    echo "<pre>";
    print_r($s);
    echo "</pre>";
}
use Pheanstalk\Pheanstalk;
$pheanstalk = new Pheanstalk('127.0.0.1');  //initiating an object
$watches = $pheanstalk->watch("ashimatube103613");
if ($pheanstalk->getConnection()->isServiceListening() == true) {  
    p($job = $pheanstalk->reserve());  
    while($job = $pheanstalk->reserve()) {
        $getdata = $job->getData();     
        p($getdata);
        echo 'test this is ';   
        $pheanstalk->delete($job);
    } 
}
$start  = $pheanstalk->getConnection()->isServiceListening(); // true or false
echo $start."listening";
try {
    # $job = $pheanstalk->reserve();
    # p($job->getData());
    echo 'here test';
} catch (Exception $e) {
    echo "Error sending message - {$e->getMessage()} \n";
}

What have I done wrong?

Here is my producer code: producer.php

<?php 
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
#echo phpinfo();
require("vendor/autoload.php");

function p($s){
    echo "<pre>";
    print_r($s);
    echo "</pre>";
}
use Pheanstalk\Pheanstalk;


$pheanstalk = new Pheanstalk('127.0.0.1');  //initiating an object

$args = array(
    "date" => "2017-1-17",
    "id"=>array("7","8","39","4")
);

#producer
$put = $pheanstalk->useTube("ashimatube103613")->put(json_encode(array($args)));
exit();
TRiG
  • 10,148
  • 7
  • 57
  • 107
  • 1
    Post your code here, not on an external site. – Barmar Jan 17 '17 at 05:20
  • i have updated the codes sorry @Barmar – Jessica Thompson Jan 17 '17 at 05:45
  • on the server command here is the status command. current-jobs-urgent: 0 current-jobs-ready: 0 current-jobs-reserved: 3 current-jobs-delayed: 0 current-jobs-buried: 0 cmd-put: 3 cmd-peek: 0 cmd-peek-ready: 0 cmd-peek-delayed: 0 cmd-peek-buried: 0 cmd-reserve: 18 cmd-reserve-with-timeout: 0 cmd-delete: 0 cmd-release: 0 cmd-use: 3 cmd-watch: 11 – Jessica Thompson Jan 17 '17 at 05:48
  • cmd-watch: 11 cmd-ignore: 0 cmd-bury: 0 cmd-kick: 0 cmd-touch: 0 cmd-stats: 3 cmd-stats-job: 0 cmd-stats-tube: 0 cmd-list-tubes: 0 cmd-list-tube-used: 0 cmd-list-tubes-watched: 0 cmd-pause-tube: 0 job-timeouts: 0 total-jobs: 3 max-job-size: 65535 current-tubes: 2 current-connections: 8 current-producers: 0 current-workers: 7 current-waiting: 7 total-connections: 17 pid: 12380 version: 1.4.6 rusage-utime: 0.000000 rusage-stime: 0.004000 uptime: 953 binlog-oldest-index: 0 binlog-current-index: 0 binlog-max-size: 10485760 – Jessica Thompson Jan 17 '17 at 05:49
  • That's really hard to read in comments. Anything that's important to the question should be in the question itself, not in comments. – Barmar Jan 17 '17 at 17:38
  • I don't understand the question. What do you mean by "It always get the value on the old"? – Barmar Jan 17 '17 at 17:46

1 Answers1

0

You probably want an infinite loop. A lot of sample code for workers/listeners has infinite loops, and this is probably the simplest method to achieve your aims. It shouldn’t be running through the webserver, so it isn’t constrained by Apache’s or Nginx’s timeout limit: this code can run effectively for ever. And it probably should. It needs to be constantly watching the queue, so that it always knows when a new task arrives which it can process.

Dayle Rees has a short tutorial on message queues (not on Beanstalkd specifically) which explains this well.


However, if you edit running PHP code, those changes have no effect until execution completes. The next time the code is invoked, it will run your new code. Therefore, infinitely running code makes deployment difficult. You need to somehow stop it, and then restart it, for the deployed changes to have any effect.

One alternative, therefore, is to have your listener exit after each job processed (and also after a given length of time with no jobs to process), and use Supervisor or some similar system to manage the process, ensuring that it restarts each time it stops. This is the approach taken by a tutorial on Sitepoint.

$job = $queue->reserve(60 * 5);

This will return as soon as a job is available, or after five minutes. If $job is a job, we do the work that job defines for us to do, and then exit; if $job is false, we simply exit immediately, as we have nothing to do. Either way, it is the job of Supervisor to ensure that the script starts up again. Supervisor can also be configured to run multiple instances of the script, if desired.

The Supervisor method certainly has more flexibility, but at the cost of increased difficulty of initial setup, unless you’re already familiar with Supervisor. (Note that Supervisor isn’t the only program that can manage other scripts like this.)

TRiG
  • 10,148
  • 7
  • 57
  • 107