Beanstalkd is logging this message in error log. I can't find any useful information about this message.
What does it mean, should we worry about it?
I've just looked at the Beanstalkd source code and there doesn't appear to be any such message there. Are you running some kind of customised version?
Related
Is it possible to somehow view sidekiq completed job list - for example, find all PurchaseWorkers with params (1)? Yesterday in my app delayed method that was supposed to run didn't and associated entity (lets say 'purchase') got stuck in limbo with state "processing". I am trying to understand whats the reason: job wasn't en-queued at all or was en-queued but for some reason exited unexpectedly. There were no errors in sidekiq log.
Thanks.
This is old but I wanted to see the same thing since I'm not sure if jobs I scheduled ran or not!
Turns out, Sidekiq doesn't have anything built in to see jobs that completed and still doesn't seem to.
If it err'd and never completes it should be in the 'dead' queue. But to check that something actually ran seems to be beyond Sidekiq by default.
The FAQ suggests installing 3rd party plugins to track and log information: https://github.com/mperham/sidekiq/wiki/FAQ#how-can-i-tell-when-a-job-has-finished One of them allows for having a callback to do follow up (maybe add a record for completed jobs elsewhere?)
You can also setup Sidekiq to log to somewhere other than STDOUT (default) so you can output log information about your jobs. In this case, logging that it's complete or catching errors if for some reason it is never landing in the retrying or dead jobs queue when there is a problem. See https://github.com/mperham/sidekiq/wiki/Logging
To see jobs still in queue you can use the Rails console and look at the queue by queue name https://www.rubydoc.info/gems/sidekiq/Sidekiq/Queue
One option is the default stats provided by sidekiq - https://github.com/mperham/sidekiq/wiki/Monitoring#using-the-built-in-dashboard
The best options is to use the Web UI provided here - https://github.com/mperham/sidekiq/wiki/Monitoring#web-ui
I have started to look into Beanstalkd for queuing my Jobs for processing, I have following questions though that I request answers to:
Where can I enable Beanstalkd logging and where is the log file ?, so that in the event of issues from Beanstalkd , I can actually identify what the issue was.
What kind of performance impact is there if file sync for jobs is enabled and used?
How can I monitor the health of Beanstalkd and what are the vital health parameters of Beanstalkd that can be accessed via the running Beanstalkd application?
Please reply me with relevant answers/links.
thanks in advance
Ashish Sharma
Currently logging is not possible, there is a feature request here.
File sync for jobs must be enabled to have persistent mode. The impact is minimal, you don't notice it. You can still process 10k ops/second without any performance hit.
You can check out beanstalk admin panel it provides some numbers, that would help you at the beginning. But you have graph, nagios plugin available on the tools page.
You can check out other beanstalkd tools here.
I am trying to use the Queue system in Laravel (4.1). Everything works as expected, with both Redis (with the native driver) and RabbitMQ.
The only "issue" I am experiencing is the poor performance. It looks like only 4 jobs per seconds can be processed (I push 1000 jobs in the queue to test it). Have you got any tip to improve the performance?
This is a old question but I thought I would post anyway. The problem is Laravel's default listener is not really a true queue consumer, it polls the queue at regular intervals unless it is already busy with a job. Using a true AMQP requires some additional libraries to be install from pecl. You can find that plugin here. I would also suggest using this composer package for you PHP AMQP library. You would then need to write your Laravel command.
Currently I'm writing a RabbitMQ handler for Laravel that will resolve this issue.
Old question, but for anyone coming here, the queue:work command has a daemon mode that runs just like queue:listen except that it doesn't have to restart/reload Laravel each time, making it much more performant. See the docs:
http://laravel.com/docs/4.2/queues
My app runs on Heroku with unicorn and uses sucker_punch to send a small quantity of emails in the background without slowing the web UI. This has been working pretty well for a few weeks.
I changed the unicorn config to the Heroku recommended config. The recommended config
includes an option for the number of unicorn processes and I upped the number of processes from 2 to 3.
Apparently that was too much. The sucker_punch jobs stopped running. I have log messages that indicate when they are queued and I have messages that indicate when they start processing. The log shows them being queued but the processing never starts.
My theory is that I exceeded memory by going from 2 to 3 unicorns.
I did not find a message anywhere indicating a problem.
Q1: should I expect to find a failure messsage somewhere? Something like "attempting to start sucker_punch -- oops, not enough memory"?
Q2: Any suggestions on how I can be notified of a failure like this in the future.
Thanks.
If you are indeed exceeding dyno memory, you should find R14 or R15 errors in your logs. See https://devcenter.heroku.com/articles/error-codes#r14-memory-quota-exceeded
A more likely problem, though, given that you haven't found these errors, is that something within the perform method of your sucker punch worker is throwing an exception. I've found sucker punch tasks to be a pain to debug because it appears the lib swallows all exceptions silently. Try instantiating your task and calling perform on it from a rails console to make sure that it behaves as you expect.
For example, you should be able to do this without causing an exception:
task = YourTask.new
task.perform :something, 55
I am running a listener program on a JMS queue hosted in Sun Java System Application Server 9.1_02 (build b08-p03)
After receiving a message I will extract and log some details in to a log file.
I observed that when running listener for really long hours, it stops receiving messages. I had to manually stop the program and start it again. Then it receives some 200-300 message and then stops again. I had to restart it to retrieve another set of messages.
Why is this weird behavior? Can someone throw light on this?
Thank you
Chaitanya
I found the issue myself. I am running the listener as Load Runner Java Vuser script. One negative thing about LR is that it does not show any exceptions. The script appears to be running but it actually does nothing. I found this when I ported the script to Eclipse and found that the script is throwing exceptions. This is essentially because I am not checking for a certain condition.
Happy that I demystified at last!
Thanks.