New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

queue:listen not working #579

Closed
ryanhungate opened this Issue Mar 14, 2013 · 42 comments

Comments

Projects
None yet
10 participants
@ryanhungate

ryanhungate commented Mar 14, 2013

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Mar 14, 2013

Member

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Member

taylorotwell commented Mar 14, 2013

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 14, 2013

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

ryanhungate commented Mar 14, 2013

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Mar 14, 2013

Member

When's the last time you composer updated?

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Member

taylorotwell commented Mar 14, 2013

When's the last time you composer updated?

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Mar 14, 2013

Member

You may also try logging something like the connection name in Queue\Worker

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Member

taylorotwell commented Mar 14, 2013

You may also try logging something like the connection name in Queue\Worker

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 14, 2013

if the queue:work command works fine wouldn't everything be kosher? Where would I log it, i feel like there are a lot of moving pieces in that workflow, so any help would speed things up…

Thanks for the help, hopefully I can nail this one down real quick.

On Mar 14, 2013, at 4:53 PM, Taylor Otwell wrote:

You may also try logging something like the connection name in Queue\Worker

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

ryanhungate commented Mar 14, 2013

if the queue:work command works fine wouldn't everything be kosher? Where would I log it, i feel like there are a lot of moving pieces in that workflow, so any help would speed things up…

Thanks for the help, hopefully I can nail this one down real quick.

On Mar 14, 2013, at 4:53 PM, Taylor Otwell wrote:

You may also try logging something like the connection name in Queue\Worker

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 15, 2013

sorry for the double post… so how do you recommend running this on a production server to constantly listen and respond?

On Mar 14, 2013, at 4:53 PM, Taylor Otwell wrote:

You may also try logging something like the connection name in Queue\Worker

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

ryanhungate commented Mar 15, 2013

sorry for the double post… so how do you recommend running this on a production server to constantly listen and respond?

On Mar 14, 2013, at 4:53 PM, Taylor Otwell wrote:

You may also try logging something like the connection name in Queue\Worker

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Mar 15, 2013

Member

We use supervisord at work to keep the queue:listen process up... Skype me (userscape.taylor)

On Mar 14, 2013, at 7:01 PM, Ryan Hungate notifications@github.com wrote:

sorry for the double post… so how do you recommend running this on a production server to constantly listen and respond?

On Mar 14, 2013, at 4:53 PM, Taylor Otwell wrote:

You may also try logging something like the connection name in Queue\Worker

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Member

taylorotwell commented Mar 15, 2013

We use supervisord at work to keep the queue:listen process up... Skype me (userscape.taylor)

On Mar 14, 2013, at 7:01 PM, Ryan Hungate notifications@github.com wrote:

sorry for the double post… so how do you recommend running this on a production server to constantly listen and respond?

On Mar 14, 2013, at 4:53 PM, Taylor Otwell wrote:

You may also try logging something like the connection name in Queue\Worker

On Mar 14, 2013, at 6:49 PM, Ryan Hungate notifications@github.com wrote:

no not an error, it just doesn't seem to pick up the queued item. I'll try it again but it doesn't seem to be right now.

just running:
php artisan queue:listen

I am doing a print statement right before the new Process() part to debug it, and it says :
php artisan queue:work --queue=default --delay=0 --memory=128 --sleep

Does the --sleep need to be set or something?

On Mar 14, 2013, at 4:36 PM, Taylor Otwell wrote:

Do you get an error? Also, which exact command are you running?

On Mar 14, 2013, at 6:07 PM, Ryan Hungate notifications@github.com wrote:

Is there anything that I could be missing here, where the queue:work command works fine, but the queue:listen does not pick up the queued items on demand... really frustrating. Please let me know what your doing on this. I am also using IronMQ at the moment, everything seems to work fine other than the listen part, which is really the most important.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 20, 2013

Hey Taylor, I am starting a process in the --env=staging environment, but the listener doesnt actually pick up the right environment. I think that it needs to be checked if any extra configs were set, to also write those out to the makeProcess() method...

ryanhungate commented Mar 20, 2013

Hey Taylor, I am starting a process in the --env=staging environment, but the listener doesnt actually pick up the right environment. I think that it needs to be checked if any extra configs were set, to also write those out to the makeProcess() method...

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Mar 20, 2013

Member

OK, will check that out.

Member

taylorotwell commented Mar 20, 2013

OK, will check that out.

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Mar 20, 2013

Member

Just pushed a fix!

Member

taylorotwell commented Mar 20, 2013

Just pushed a fix!

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 20, 2013

NICE! Thanks dude... really appreciate the help.

ryanhungate commented Mar 20, 2013

NICE! Thanks dude... really appreciate the help.

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 21, 2013

Hey Taylor... just so you know, I was getting an error saying that laravel was not an object jin the Console/ListenCommand construct() function...

I dont know what Im talking about, but I think it needs to be in:

    public function fire()
    {
            $this->listener->setEnvironment($this->laravel->environment());
    }

section... I changed that and it worked. Is this right?

ryanhungate commented Mar 21, 2013

Hey Taylor... just so you know, I was getting an error saying that laravel was not an object jin the Console/ListenCommand construct() function...

I dont know what Im talking about, but I think it needs to be in:

    public function fire()
    {
            $this->listener->setEnvironment($this->laravel->environment());
    }

section... I changed that and it worked. Is this right?

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Mar 21, 2013

Member

I made a fix for this last night I believe

On Mar 20, 2013, at 8:30 PM, Ryan Hungate notifications@github.com wrote:

Hey Taylor... just so you know, I was getting an error saying that laravel was not an object jin the Console/ListenCommand construct() function...

I dont know what Im talking about, but I think it needs to be in:

public function fire()
{
        $this->listener->setEnvironment($this->laravel->environment());
}

section... I changed that and it worked. Is this right?


Reply to this email directly or view it on GitHub.

Member

taylorotwell commented Mar 21, 2013

I made a fix for this last night I believe

On Mar 20, 2013, at 8:30 PM, Ryan Hungate notifications@github.com wrote:

Hey Taylor... just so you know, I was getting an error saying that laravel was not an object jin the Console/ListenCommand construct() function...

I dont know what Im talking about, but I think it needs to be in:

public function fire()
{
        $this->listener->setEnvironment($this->laravel->environment());
}

section... I changed that and it worked. Is this right?


Reply to this email directly or view it on GitHub.

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 21, 2013

Cool... ill check and beat it up tomorrow. Thanks
On Mar 20, 2013 6:35 PM, "Taylor Otwell" notifications@github.com wrote:

I made a fix for this last night I believe

On Mar 20, 2013, at 8:30 PM, Ryan Hungate notifications@github.com
wrote:

Hey Taylor... just so you know, I was getting an error saying that
laravel was not an object jin the Console/ListenCommand construct()
function...

I dont know what Im talking about, but I think it needs to be in:

public function fire()
{
$this->listener->setEnvironment($this->laravel->environment());
}
section... I changed that and it worked. Is this right?


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com//issues/579#issuecomment-15214742
.

ryanhungate commented Mar 21, 2013

Cool... ill check and beat it up tomorrow. Thanks
On Mar 20, 2013 6:35 PM, "Taylor Otwell" notifications@github.com wrote:

I made a fix for this last night I believe

On Mar 20, 2013, at 8:30 PM, Ryan Hungate notifications@github.com
wrote:

Hey Taylor... just so you know, I was getting an error saying that
laravel was not an object jin the Console/ListenCommand construct()
function...

I dont know what Im talking about, but I think it needs to be in:

public function fire()
{
$this->listener->setEnvironment($this->laravel->environment());
}
section... I changed that and it worked. Is this right?


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com//issues/579#issuecomment-15214742
.

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 28, 2013

Hey, update on the queue issue...

So i installed supervisord - the listener fires just fine, because I can specify the path in the command for listening -

The issue is that in the Listener class, it creates the process ( php artisan )... which has no path defined. It seems as if that will not work the way it is set up... shouldn't there be a path setting in there to make sure it gets fired up the right way, or am I off on this one?

    /usr/local/bin/php  /root/project/artisan queue:listen iron --env=production

??

ryanhungate commented Mar 28, 2013

Hey, update on the queue issue...

So i installed supervisord - the listener fires just fine, because I can specify the path in the command for listening -

The issue is that in the Listener class, it creates the process ( php artisan )... which has no path defined. It seems as if that will not work the way it is set up... shouldn't there be a path setting in there to make sure it gets fired up the right way, or am I off on this one?

    /usr/local/bin/php  /root/project/artisan queue:listen iron --env=production

??

@JoostK

This comment has been minimized.

Show comment
Hide comment
@JoostK

JoostK Mar 28, 2013

Contributor

With supervisord you can set the current working dir (see the directory directive), doesn't that work?

Contributor

JoostK commented Mar 28, 2013

With supervisord you can set the current working dir (see the directory directive), doesn't that work?

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 28, 2013

hmm, if your saying that I can just one config line to the supervisor config in the correct program, that it will automatically know to run it correctly? I am just not that great with all the linux stuff. Thanks for the help

ryanhungate commented Mar 28, 2013

hmm, if your saying that I can just one config line to the supervisor config in the correct program, that it will automatically know to run it correctly? I am just not that great with all the linux stuff. Thanks for the help

@JoostK

This comment has been minimized.

Show comment
Hide comment
@JoostK

JoostK Mar 28, 2013

Contributor

Correct. Look at the directory item here: http://supervisord.org/configuration.html#program-x-section-settings

I recently setup a supervisord as php artisan ... (so with relative artisan path) and with directory set properly in supervisord.conf, it works (not a spawned process, I'm not using that, but I think it'll work for you here)

Contributor

JoostK commented Mar 28, 2013

Correct. Look at the directory item here: http://supervisord.org/configuration.html#program-x-section-settings

I recently setup a supervisord as php artisan ... (so with relative artisan path) and with directory set properly in supervisord.conf, it works (not a spawned process, I'm not using that, but I think it'll work for you here)

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 28, 2013

hmm... I just cant figure this one out. I tried the directory thing, restarted supervisor, and nothing. This is my supervisor config file:

    [program:queue_staging]
    command=/usr/local/bin/php /path/tocode/artisan queue:listen iron --env=staging
    stdout_logfile=/path/to/code/app/storage/logs/queue/iron.txt
    directory=/path/to/code
    autorestart=true

I am using the respawning because that's the real point of the listener... so for now, I have the thing hard coded into the Laravel LIstener, but I want to remove that ASAP... any advice would be great.

ryanhungate commented Mar 28, 2013

hmm... I just cant figure this one out. I tried the directory thing, restarted supervisor, and nothing. This is my supervisor config file:

    [program:queue_staging]
    command=/usr/local/bin/php /path/tocode/artisan queue:listen iron --env=staging
    stdout_logfile=/path/to/code/app/storage/logs/queue/iron.txt
    directory=/path/to/code
    autorestart=true

I am using the respawning because that's the real point of the listener... so for now, I have the thing hard coded into the Laravel LIstener, but I want to remove that ASAP... any advice would be great.

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Mar 28, 2013

Member

Yeah we either need to detect the binary used to run listen and use the same for work, or have --bin option.

Sent from Mailbox for iPhone

On Thu, Mar 28, 2013 at 6:37 PM, Ryan Hungate notifications@github.com
wrote:

hmm... I just cant figure this one out. I tried the directory thing, restarted supervisor, and nothing. This is my supervisor config file:
[program:queue_staging]
command=/usr/local/bin/php /path/tocode/artisan queue:listen iron --env=staging
stdout_logfile=/path/to/code/app/storage/logs/queue/iron.txt
directory=/path/to/code
autorestart=true

I am using the respawning because that's the real point of the listener... so for now, I have the thing hard coded into the Laravel LIstener, but I want to remove that ASAP... any advice would be great.

Reply to this email directly or view it on GitHub:
#579 (comment)

Member

taylorotwell commented Mar 28, 2013

Yeah we either need to detect the binary used to run listen and use the same for work, or have --bin option.

Sent from Mailbox for iPhone

On Thu, Mar 28, 2013 at 6:37 PM, Ryan Hungate notifications@github.com
wrote:

hmm... I just cant figure this one out. I tried the directory thing, restarted supervisor, and nothing. This is my supervisor config file:
[program:queue_staging]
command=/usr/local/bin/php /path/tocode/artisan queue:listen iron --env=staging
stdout_logfile=/path/to/code/app/storage/logs/queue/iron.txt
directory=/path/to/code
autorestart=true

I am using the respawning because that's the real point of the listener... so for now, I have the thing hard coded into the Laravel LIstener, but I want to remove that ASAP... any advice would be great.

Reply to this email directly or view it on GitHub:
#579 (comment)

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 29, 2013

why not just have the -bin option… were setting that up in the supervisor config, so its not like its going to be a hassle.

On Mar 28, 2013, at 4:55 PM, Taylor Otwell wrote:

Yeah we either need to detect the binary used to run listen and use the same for work, or have --bin option.

Sent from Mailbox for iPhone

On Thu, Mar 28, 2013 at 6:37 PM, Ryan Hungate notifications@github.com
wrote:

hmm... I just cant figure this one out. I tried the directory thing, restarted supervisor, and nothing. This is my supervisor config file:
[program:queue_staging]
command=/usr/local/bin/php /path/tocode/artisan queue:listen iron --env=staging
stdout_logfile=/path/to/code/app/storage/logs/queue/iron.txt
directory=/path/to/code
autorestart=true

I am using the respawning because that's the real point of the listener... so for now, I have the thing hard coded into the Laravel LIstener, but I want to remove that ASAP... any advice would be great.

Reply to this email directly or view it on GitHub:
#579 (comment)

Reply to this email directly or view it on GitHub.

ryanhungate commented Mar 29, 2013

why not just have the -bin option… were setting that up in the supervisor config, so its not like its going to be a hassle.

On Mar 28, 2013, at 4:55 PM, Taylor Otwell wrote:

Yeah we either need to detect the binary used to run listen and use the same for work, or have --bin option.

Sent from Mailbox for iPhone

On Thu, Mar 28, 2013 at 6:37 PM, Ryan Hungate notifications@github.com
wrote:

hmm... I just cant figure this one out. I tried the directory thing, restarted supervisor, and nothing. This is my supervisor config file:
[program:queue_staging]
command=/usr/local/bin/php /path/tocode/artisan queue:listen iron --env=staging
stdout_logfile=/path/to/code/app/storage/logs/queue/iron.txt
directory=/path/to/code
autorestart=true

I am using the respawning because that's the real point of the listener... so for now, I have the thing hard coded into the Laravel LIstener, but I want to remove that ASAP... any advice would be great.

Reply to this email directly or view it on GitHub:
#579 (comment)

Reply to this email directly or view it on GitHub.

@dvcrn

This comment has been minimized.

Show comment
Hide comment
@dvcrn

dvcrn Feb 28, 2014

I ran into the exact same issue. The one-off worker is doing fine while the listener is simply doing nothing.
Did you find a solution for your problem @ryanhungate?

dvcrn commented Feb 28, 2014

I ran into the exact same issue. The one-off worker is doing fine while the listener is simply doing nothing.
Did you find a solution for your problem @ryanhungate?

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Feb 28, 2014

@dabido 3 things:

  1. We switched to Monit for the process monitor. It has been great and easy to use.

  2. When I run the listener in the background, we are specifying the exact php path, so in our case, its:

    check process queue_listen_my_queue with pidfile /tmp/queue_listen_my_queue.pid
      noalert notify@example.com
      start program = "/bin/su LINUX_USER -c '/usr/bin/php /var/www/path/to/artisan queue:listen & echo $! > /tmp/queue_listen_my_queue.pid'"
      stop  program = "/bin/bash -c '/bin/kill -9 $(cat /tmp/queue_listen_my_queue.pid)'"
    
  3. I wrote our own little wrapper for the queue ( not shown here in the path ), which has its own local db queue processor, rather than using any 3rd party MQ center, mainly because I wanted the ability to name jobs for referencing, and keep track of the queues that were polling on.

If your using say IronMQ or another provider that supports push queues, you should probably switch to the push queue method, and listen for webhooks to lighten the load on your server resources.

What I have done, is set up a new Monit process for each queue that needs to be polled, so that if I needed to shut down one of them for a bit, it was not a problem. The only downfall to this is that your loading up an app in memory for each listener you turn on...

ryanhungate commented Feb 28, 2014

@dabido 3 things:

  1. We switched to Monit for the process monitor. It has been great and easy to use.

  2. When I run the listener in the background, we are specifying the exact php path, so in our case, its:

    check process queue_listen_my_queue with pidfile /tmp/queue_listen_my_queue.pid
      noalert notify@example.com
      start program = "/bin/su LINUX_USER -c '/usr/bin/php /var/www/path/to/artisan queue:listen & echo $! > /tmp/queue_listen_my_queue.pid'"
      stop  program = "/bin/bash -c '/bin/kill -9 $(cat /tmp/queue_listen_my_queue.pid)'"
    
  3. I wrote our own little wrapper for the queue ( not shown here in the path ), which has its own local db queue processor, rather than using any 3rd party MQ center, mainly because I wanted the ability to name jobs for referencing, and keep track of the queues that were polling on.

If your using say IronMQ or another provider that supports push queues, you should probably switch to the push queue method, and listen for webhooks to lighten the load on your server resources.

What I have done, is set up a new Monit process for each queue that needs to be polled, so that if I needed to shut down one of them for a bit, it was not a problem. The only downfall to this is that your loading up an app in memory for each listener you turn on...

@dvcrn

This comment has been minimized.

Show comment
Hide comment
@dvcrn

dvcrn Mar 1, 2014

@ryanhungate that sounds like a solution for the whole worker thing. All I want to do for now is get the listener running, which seems to be way harder than expected.

I am currently using the built in beanstalkd connector worker laravel ships with and run our listener with /usr/bin/php /var/www/myproject/artisan queue:listen --queue=default --env=staging - everything is already absolute.

/usr/bin/php /var/www/myproject/artisan queue:work --queue=default --env=staging is working fine.

I slowly feel it would be easier to simply switch to amqp and write a independent RabbitMQ worker.

dvcrn commented Mar 1, 2014

@ryanhungate that sounds like a solution for the whole worker thing. All I want to do for now is get the listener running, which seems to be way harder than expected.

I am currently using the built in beanstalkd connector worker laravel ships with and run our listener with /usr/bin/php /var/www/myproject/artisan queue:listen --queue=default --env=staging - everything is already absolute.

/usr/bin/php /var/www/myproject/artisan queue:work --queue=default --env=staging is working fine.

I slowly feel it would be easier to simply switch to amqp and write a independent RabbitMQ worker.

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 1, 2014

@dabido what's the actual problem? Is it that you can only get this thing running in the terminal, and when you close it, it stops? If that's the case, the use case is exactly what I had said to use Monit for. You need to make sure the php process lives in daemon mode all the time with a process monitor like that. ( sorry if you already knew that ).

ryanhungate commented Mar 1, 2014

@dabido what's the actual problem? Is it that you can only get this thing running in the terminal, and when you close it, it stops? If that's the case, the use case is exactly what I had said to use Monit for. You need to make sure the php process lives in daemon mode all the time with a process monitor like that. ( sorry if you already knew that ).

@dvcrn

This comment has been minimized.

Show comment
Hide comment
@dvcrn

dvcrn Mar 2, 2014

@ryanhungate apologies, maybe I misunderstood your initial issue and replied wrong. My problem is, the laravel queue listener is simply doing nothing, while queue:work is, well, working fine.

When I start the listener and push some testdata in a separate terminal into the queue, the listener is not picking up new items. It just does nothing.

I believe this was your initial problem on this issue?

dvcrn commented Mar 2, 2014

@ryanhungate apologies, maybe I misunderstood your initial issue and replied wrong. My problem is, the laravel queue listener is simply doing nothing, while queue:work is, well, working fine.

When I start the listener and push some testdata in a separate terminal into the queue, the listener is not picking up new items. It just does nothing.

I believe this was your initial problem on this issue?

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 2, 2014

@dabido ok, I remember that when this happened to me, and im pretty sure this will solve your problem, is that in the actual Laravel Queue Listener file, you will probably have to hard code your php path in the command string where it is currently hard coded :
https://github.com/laravel/framework/blob/master/src/Illuminate/Queue/Listener.php#L41

just change that to your correct path and then see if that works.

ryanhungate commented Mar 2, 2014

@dabido ok, I remember that when this happened to me, and im pretty sure this will solve your problem, is that in the actual Laravel Queue Listener file, you will probably have to hard code your php path in the command string where it is currently hard coded :
https://github.com/laravel/framework/blob/master/src/Illuminate/Queue/Listener.php#L41

just change that to your correct path and then see if that works.

@dcarrith

This comment has been minimized.

Show comment
Hide comment
@dcarrith

dcarrith Mar 2, 2014

Contributor

@dabido - I have encountered a similar scenario where the queue listener seems like it isn't doing anything. What driver are you using? I have tested the IronMQ, Beanstalkd and SQS drivers and in my testing, it usually came down to how I was pushing things onto the queue. If my listener was configured to listen for the queue named 'default', but I was explicitly trying to push things onto the queue named 'emails' then it would appear that my listener was not doing anything because in fact it wasn't. After I made that connection, I set up my queue listeners to listen for the two different queues I was using, and then all worked fine with the exception of the SQS driver. For that, I had to listen for and push using the entire QueueUrl for the queue in question. I actually ended up modifying the SqsQueue.php (and one other file) so that I could listen and push just using the queue name just like the other two 3rd party drivers. I'm working on a PR for this, but am trying to implement some tests first.

By the way, I'm using supervisord to deploy the listeners:

[program:queueEmails]
command                 = bash -c "ulimit -n 10000 && cd /absolute/path/to/htdocs/ && /absolute/path/to/php/bin/php artisan queue:listen --queue=emails --tries=3 --verbose >>./app/storage/logs/queueEmails.log 2>&1"
process_name            = queueEmails
numprocs                = 1
autostart               = true
autorestart             = true
user                    = root
stdout_logfile          = /absolute/path/to/htdocs/app/storage/logs/supervisor_queueEmails_info.log
stdout_logfile_maxbytes = 10MB
stderr_logfile          = /absolute/path/to/htdocs/app/storage/logs/supervisor_queueEmails_error.log
stderr_logfile_maxbytes = 10MB

[program:queueUploads]
command                 = bash -c "ulimit -n 10000 && cd /absolute/path/to/htdocs/ && /absolute/path/to/php/bin/php artisan queue:listen --queue=uploads --tries=3 --verbose >>./app/storage/logs/queueUploads.log 2>&1"
process_name            = queueUploads
numprocs                = 1
autostart               = true
autorestart             = true
user                    = root
stdout_logfile          = /absolute/path/to/htdocs/app/storage/logs/supervisor_queueUploads_info.log
stdout_logfile_maxbytes = 10MB
stderr_logfile          = /absolute/path/to/htdocs/app/storage/logs/supervisor_queueUploads_error.log
stderr_logfile_maxbytes = 10MB

Note: I know it's probably not a good idea to run as root, but I'm still in the testing phases.

In my login controller I have this line to push a job onto the queue:

Queue::push('MailHandler@send', array('first_name' => Auth::user()->first_name), 'emails');

The MailHandler@send just sends an email to the admin when someone logs in (just as a test).

The queueUploads is a more interesting listener, and for that, I have this line in my uploads controller to push a job onto the queue:

Queue::push( 'FileUploadsHandler@organize', $data, 'uploads' );

The FileUploadsHandler@organize handler takes the path to the uploaded file, parses the MP3 tags, and then creates directories and moves the file to it's permanent place.

As you see above, I'm explicitly pushing onto the emails and uploads queue. Therefore, I have listeners for each queue as well.

Contributor

dcarrith commented Mar 2, 2014

@dabido - I have encountered a similar scenario where the queue listener seems like it isn't doing anything. What driver are you using? I have tested the IronMQ, Beanstalkd and SQS drivers and in my testing, it usually came down to how I was pushing things onto the queue. If my listener was configured to listen for the queue named 'default', but I was explicitly trying to push things onto the queue named 'emails' then it would appear that my listener was not doing anything because in fact it wasn't. After I made that connection, I set up my queue listeners to listen for the two different queues I was using, and then all worked fine with the exception of the SQS driver. For that, I had to listen for and push using the entire QueueUrl for the queue in question. I actually ended up modifying the SqsQueue.php (and one other file) so that I could listen and push just using the queue name just like the other two 3rd party drivers. I'm working on a PR for this, but am trying to implement some tests first.

By the way, I'm using supervisord to deploy the listeners:

[program:queueEmails]
command                 = bash -c "ulimit -n 10000 && cd /absolute/path/to/htdocs/ && /absolute/path/to/php/bin/php artisan queue:listen --queue=emails --tries=3 --verbose >>./app/storage/logs/queueEmails.log 2>&1"
process_name            = queueEmails
numprocs                = 1
autostart               = true
autorestart             = true
user                    = root
stdout_logfile          = /absolute/path/to/htdocs/app/storage/logs/supervisor_queueEmails_info.log
stdout_logfile_maxbytes = 10MB
stderr_logfile          = /absolute/path/to/htdocs/app/storage/logs/supervisor_queueEmails_error.log
stderr_logfile_maxbytes = 10MB

[program:queueUploads]
command                 = bash -c "ulimit -n 10000 && cd /absolute/path/to/htdocs/ && /absolute/path/to/php/bin/php artisan queue:listen --queue=uploads --tries=3 --verbose >>./app/storage/logs/queueUploads.log 2>&1"
process_name            = queueUploads
numprocs                = 1
autostart               = true
autorestart             = true
user                    = root
stdout_logfile          = /absolute/path/to/htdocs/app/storage/logs/supervisor_queueUploads_info.log
stdout_logfile_maxbytes = 10MB
stderr_logfile          = /absolute/path/to/htdocs/app/storage/logs/supervisor_queueUploads_error.log
stderr_logfile_maxbytes = 10MB

Note: I know it's probably not a good idea to run as root, but I'm still in the testing phases.

In my login controller I have this line to push a job onto the queue:

Queue::push('MailHandler@send', array('first_name' => Auth::user()->first_name), 'emails');

The MailHandler@send just sends an email to the admin when someone logs in (just as a test).

The queueUploads is a more interesting listener, and for that, I have this line in my uploads controller to push a job onto the queue:

Queue::push( 'FileUploadsHandler@organize', $data, 'uploads' );

The FileUploadsHandler@organize handler takes the path to the uploaded file, parses the MP3 tags, and then creates directories and moves the file to it's permanent place.

As you see above, I'm explicitly pushing onto the emails and uploads queue. Therefore, I have listeners for each queue as well.

@dvcrn

This comment has been minimized.

Show comment
Hide comment
@dvcrn

dvcrn Mar 3, 2014

@ryanhungate sadly that didn't help either. The worker still seems to do absolutely nothing

@dcarrith I am using the beanstalkd queue and, as written, the queue:work command is doing fine. Just the listener is not working.

I am pushing to the queue with

Queue::push('Namespace\To\Worker', array('param' => $someVar), 'myqueue');

Everything I push arrived in the queue correctly, so that shouldn't be the problem.

I am leaving the specific function call since fire() does fine for my needs. Adding a function name isn't changing anything though. Tried that already.

I am spawning a worker with:
/usr/bin/php artisan queue:work --queue=myqueue --verbose

or a listener with
/usr/bin/php artisan queue:listen --queue=myqueue --verbose

I hardcoded the environment into start.php to exclude that for the error source.
I am not at the point where I can deploy the listener, so I am simply running it off the terminal.

If you have more ideas, I'm happy to try!

dvcrn commented Mar 3, 2014

@ryanhungate sadly that didn't help either. The worker still seems to do absolutely nothing

@dcarrith I am using the beanstalkd queue and, as written, the queue:work command is doing fine. Just the listener is not working.

I am pushing to the queue with

Queue::push('Namespace\To\Worker', array('param' => $someVar), 'myqueue');

Everything I push arrived in the queue correctly, so that shouldn't be the problem.

I am leaving the specific function call since fire() does fine for my needs. Adding a function name isn't changing anything though. Tried that already.

I am spawning a worker with:
/usr/bin/php artisan queue:work --queue=myqueue --verbose

or a listener with
/usr/bin/php artisan queue:listen --queue=myqueue --verbose

I hardcoded the environment into start.php to exclude that for the error source.
I am not at the point where I can deploy the listener, so I am simply running it off the terminal.

If you have more ideas, I'm happy to try!

@dvcrn

This comment has been minimized.

Show comment
Hide comment
@dvcrn

dvcrn Mar 3, 2014

OK, right after posting my comment, the solution came in my mind. The issue was basically happening due to my lack of experience in laravel and a uncaught exception.

First thing:
queue:listen does not have output! Even with the verbose flag, it just writes nothing in the terminal and therefore also not in logfiles I tried to pipe it into.

queue:work puts all the $this->output->writeLn("<info>Some info...</info>"); commands out, while queue:listen eats them up. They also don't show up in any logfile.

Second thing:
queue:listen spawns queue:work commands. On a exception, the worker crashes but the listener keeps listening without showing that something happened.

After investigating /storage/logs/xxxx.log and increasing the verbosity of the worker, I figured that a uncaught exception was flying through and crashes the worker every time laravel tries to spawn one.

Third thing:
I didn't realize that laravel isn't logging to /var/log by default. All my logs were empty and I couldn't figure out why, until I read that logs are put into app/storage/logs

I'm happy that this is finally over and my worker works 😄 Thanks for your help!

dvcrn commented Mar 3, 2014

OK, right after posting my comment, the solution came in my mind. The issue was basically happening due to my lack of experience in laravel and a uncaught exception.

First thing:
queue:listen does not have output! Even with the verbose flag, it just writes nothing in the terminal and therefore also not in logfiles I tried to pipe it into.

queue:work puts all the $this->output->writeLn("<info>Some info...</info>"); commands out, while queue:listen eats them up. They also don't show up in any logfile.

Second thing:
queue:listen spawns queue:work commands. On a exception, the worker crashes but the listener keeps listening without showing that something happened.

After investigating /storage/logs/xxxx.log and increasing the verbosity of the worker, I figured that a uncaught exception was flying through and crashes the worker every time laravel tries to spawn one.

Third thing:
I didn't realize that laravel isn't logging to /var/log by default. All my logs were empty and I couldn't figure out why, until I read that logs are put into app/storage/logs

I'm happy that this is finally over and my worker works 😄 Thanks for your help!

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 3, 2014

Hey thats why we get paid the big bucks right? :-) I always tell people
that most of the time huge issues end up getting solved with a true or
false in the wrong spot!
On Mar 2, 2014 6:02 PM, "Dave" notifications@github.com wrote:

OK, right after posting my comment, the solution came in my mind. The
issue was basically happening due to my lack of experience in laravel and a
uncaught exception.

First thing:
queue:listen does not have output! Even with the verbose flag, it just
writes nothing in the terminal and therefore also not in logfiles I tried
to pipe it into.

queue:work puts all the $this->output->writeLn("Some
info..."); commands out, while queue:listen eats them up. They
also don't show up in any logfile.

Second thing:
queue:listen spawns queue:work commands. On a exception, the worker
crashes but the listener keeps listening without showing that something
happened.

After investigating /storage/logs/xxxx.log and increasing the verbosity of
the worker, I figured that a uncaught exception was flying through and
crashes the worker every time laravel tries to spawn one.

Third thing:
I didn't realize that laravel isn't logging to /var/log by default. All my
logs were empty and I couldn't figure out why, until I read that logs are
put into /storage/logs

I'm happy that this is finally over and my worker works [image: 😄]Thanks for your help!

Reply to this email directly or view it on GitHubhttps://github.com//issues/579#issuecomment-36474357
.

ryanhungate commented Mar 3, 2014

Hey thats why we get paid the big bucks right? :-) I always tell people
that most of the time huge issues end up getting solved with a true or
false in the wrong spot!
On Mar 2, 2014 6:02 PM, "Dave" notifications@github.com wrote:

OK, right after posting my comment, the solution came in my mind. The
issue was basically happening due to my lack of experience in laravel and a
uncaught exception.

First thing:
queue:listen does not have output! Even with the verbose flag, it just
writes nothing in the terminal and therefore also not in logfiles I tried
to pipe it into.

queue:work puts all the $this->output->writeLn("Some
info..."); commands out, while queue:listen eats them up. They
also don't show up in any logfile.

Second thing:
queue:listen spawns queue:work commands. On a exception, the worker
crashes but the listener keeps listening without showing that something
happened.

After investigating /storage/logs/xxxx.log and increasing the verbosity of
the worker, I figured that a uncaught exception was flying through and
crashes the worker every time laravel tries to spawn one.

Third thing:
I didn't realize that laravel isn't logging to /var/log by default. All my
logs were empty and I couldn't figure out why, until I read that logs are
put into /storage/logs

I'm happy that this is finally over and my worker works [image: 😄]Thanks for your help!

Reply to this email directly or view it on GitHubhttps://github.com//issues/579#issuecomment-36474357
.

@ryanabrams

This comment has been minimized.

Show comment
Hide comment
@ryanabrams

ryanabrams Mar 5, 2014

I'm using queue:listen on a mac/homebrew environment, maintained via supervisor. I ran into the same issue of queue:work not actually doing anything, and this thread helped me realize it was using the mac native version of php (rather than the homebrew version).

I solved it by adding the proper path environment variable to my supervisor process configuration. Something like:

environment=PATH=/usr/local/bin:@(ENV_PATH)s

Posting it here as an alternative to manually editing the hardcoded process string.

ryanabrams commented Mar 5, 2014

I'm using queue:listen on a mac/homebrew environment, maintained via supervisor. I ran into the same issue of queue:work not actually doing anything, and this thread helped me realize it was using the mac native version of php (rather than the homebrew version).

I solved it by adding the proper path environment variable to my supervisor process configuration. Something like:

environment=PATH=/usr/local/bin:@(ENV_PATH)s

Posting it here as an alternative to manually editing the hardcoded process string.

@schickling

This comment has been minimized.

Show comment
Hide comment
@schickling

schickling Mar 10, 2014

I have a similar problem. On a production server the queue:listen command (using beanstalkd) works fine for about three days and then suddenly "stops working". The queue:listen and beanstalkd process is still running and I don't get an error while Queue::push() but the queue doesn't seem to work off its tasks.

Im starting the queue:listen command via a /etc/init.d script and not via supervisor.

Is this a beanstalkd related issue?

schickling commented Mar 10, 2014

I have a similar problem. On a production server the queue:listen command (using beanstalkd) works fine for about three days and then suddenly "stops working". The queue:listen and beanstalkd process is still running and I don't get an error while Queue::push() but the queue doesn't seem to work off its tasks.

Im starting the queue:listen command via a /etc/init.d script and not via supervisor.

Is this a beanstalkd related issue?

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 10, 2014

If your only starting this with an init script, it is not good enough. You need to have a process monitor like Monit, or Supervisor to assure that this background process does not stop working. I think that the 3 day thing is a coincidence, and that it could have been stopped after an error, or another chunk of time… Beanstalkd is operating as a background process I'm pretty sure, but either way if your going to be using this in production, you need to make sure that while your sleeping, on vacation, or simply not paying attention to that aspect of your app, that its going to be ON at all times.

On Mar 10, 2014, at 3:37 AM, Johannes Schickling wrote:

I have a similar problem. On a production server the queue:listen command (using beanstalkd) works fine for about three days and then suddenly "stops working". The queue:listen and beanstalkd process is still running and I don't get an error while Queue::push() but the queue doesn't seem to work off its tasks.

Im starting the queue:listen command via a /etc/init.d script and not via supervisor.

Is this a beanstalkd related issue?


Reply to this email directly or view it on GitHub.

ryanhungate commented Mar 10, 2014

If your only starting this with an init script, it is not good enough. You need to have a process monitor like Monit, or Supervisor to assure that this background process does not stop working. I think that the 3 day thing is a coincidence, and that it could have been stopped after an error, or another chunk of time… Beanstalkd is operating as a background process I'm pretty sure, but either way if your going to be using this in production, you need to make sure that while your sleeping, on vacation, or simply not paying attention to that aspect of your app, that its going to be ON at all times.

On Mar 10, 2014, at 3:37 AM, Johannes Schickling wrote:

I have a similar problem. On a production server the queue:listen command (using beanstalkd) works fine for about three days and then suddenly "stops working". The queue:listen and beanstalkd process is still running and I don't get an error while Queue::push() but the queue doesn't seem to work off its tasks.

Im starting the queue:listen command via a /etc/init.d script and not via supervisor.

Is this a beanstalkd related issue?


Reply to this email directly or view it on GitHub.

@schickling

This comment has been minimized.

Show comment
Hide comment
@schickling

schickling Mar 10, 2014

Thanks @ryanhungate! I'll setup supervisor asap 👍

schickling commented Mar 10, 2014

Thanks @ryanhungate! I'll setup supervisor asap 👍

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Mar 10, 2014

no problem… i have used both, and would probably recommend using Monit. Its real easy if you use those snippets that I wrote up in this feed to monitor your processes… then with a simple ( monit start my_command_name ) or ( monit restart my_command_name ) your off to the races.

On Mar 10, 2014, at 6:56 AM, Johannes Schickling wrote:

Thanks @ryanhungate! I'll setup supervisor asap


Reply to this email directly or view it on GitHub.

ryanhungate commented Mar 10, 2014

no problem… i have used both, and would probably recommend using Monit. Its real easy if you use those snippets that I wrote up in this feed to monitor your processes… then with a simple ( monit start my_command_name ) or ( monit restart my_command_name ) your off to the races.

On Mar 10, 2014, at 6:56 AM, Johannes Schickling wrote:

Thanks @ryanhungate! I'll setup supervisor asap


Reply to this email directly or view it on GitHub.

@schickling

This comment has been minimized.

Show comment
Hide comment
@schickling

schickling May 19, 2014

Similar issue: #4443

schickling commented May 19, 2014

Similar issue: #4443

@bert2002

This comment has been minimized.

Show comment
Hide comment
@bert2002

bert2002 Jan 21, 2016

@ryanhungate did you managed to start multiple instances with monit as described in the supervisord example? (https://laravel.com/docs/5.1/queues#supervisor-configuration)

bert2002 commented Jan 21, 2016

@ryanhungate did you managed to start multiple instances with monit as described in the supervisord example? (https://laravel.com/docs/5.1/queues#supervisor-configuration)

@ryanhungate

This comment has been minimized.

Show comment
Hide comment
@ryanhungate

ryanhungate Jan 21, 2016

Hey @bert2002 - Well, this was a while ago and since then I have been using Supervisor without troubles at all... Also, I have been using Taylor's services with Forge and Envoyer... I highly recommend them because not only did it solve all of my server package needs, it has become a crucial part of my workflow - deployment process. Forge lets you add workers with a few clicks of a button... My recommendation is to just do that if you haven't done that yet... It's been worth every penny we've spent with the services.

ryanhungate commented Jan 21, 2016

Hey @bert2002 - Well, this was a while ago and since then I have been using Supervisor without troubles at all... Also, I have been using Taylor's services with Forge and Envoyer... I highly recommend them because not only did it solve all of my server package needs, it has become a crucial part of my workflow - deployment process. Forge lets you add workers with a few clicks of a button... My recommendation is to just do that if you haven't done that yet... It's been worth every penny we've spent with the services.

@sachinvrg

This comment has been minimized.

Show comment
Hide comment
@sachinvrg

sachinvrg Sep 22, 2016

Can anybody please help me to figure out queue work , I am using laravel 5.2.0 and https://github.com/jenssegers/laravel-mongodb package but php artisan queue:work command not working.

sachinvrg commented Sep 22, 2016

Can anybody please help me to figure out queue work , I am using laravel 5.2.0 and https://github.com/jenssegers/laravel-mongodb package but php artisan queue:work command not working.

@themsaid

This comment has been minimized.

Show comment
Hide comment
@themsaid

themsaid Sep 22, 2016

Member

@sachinvrg I recommend you ask on the forums, it's the best place for such questions. This repo is mainly for bug reporting :)

Member

themsaid commented Sep 22, 2016

@sachinvrg I recommend you ask on the forums, it's the best place for such questions. This repo is mainly for bug reporting :)

@sachinvrg

This comment has been minimized.

Show comment
Hide comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment