Peek at complete list of jobs

[Jurian Sluiman]

I've seen similar requests on this ML before, but am not aware if any
progress is made since. What I am looking for is a method to peek all
jobs, like peek and peek-* currently do for a single job. I know it
might have drawbacks for heavy usage queues or very fast queues, but I
think this is up to the developer to decide. If a peek-all command is
load dependent, developers can choose whether or not to use it
depending on their own situation.

On the ML others have showed some good use cases why it might come in
handy, and I have something similar for myself. My jobs can succeed
(and will be deleted) or not. If not, a job might be retried later
(e.g. a request to a 3rd party service timed out) or buried (something
else happened). I want to use bury because it gives a user the
possibility to delete or kick the job. In my case it is often a human
being who can decide if a job has to be retried or deleted anyhow.

For such system an interface is required to which the user can select
one or multiple jobs to be retried and one or multiple jobs to be
deleted. For UX reasons I cannot let the user process the buried jobs
one by one.

--
Jurian Sluiman

[Keith Rarick]

If you're not concerned with performance, you can
reserve all the jobs in the tube, then release
them all again. This will give you a chance to
inspect the entire contents.

kr

> --
> You received this message because you are subscribed to the Google Groups "beanstalk-talk" group.
> To post to this group, send email to beansta...@googlegroups.com.
> To unsubscribe from this group, send email to beanstalk-tal...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en.
>

[Jurian Sluiman]

Hi Keith,

On Apr 3, 10:39 am, Keith Rarick <k...@xph.us> wrote:
> If you're not concerned with performance, you can
> reserve all the jobs in the tube, then release
> them all again. This will give you a chance to
> inspect the entire contents.
>
> kr

This is a valid option if you want to have a list of all ready jobs.
Because I want to give users the chance to kick or delete buried (i.e.
failed, in my case) jobs, is there an option to "reserve" failed jobs
without kicking them? If I kick them, they will interfere with other
normal jobs, which should be passed through to the normal workers.

--
Jurian Sluiman

[Keith Rarick]

On Tue, Apr 3, 2012 at 3:13 AM, Jurian Sluiman <jur...@juriansluiman.nl> wrote:
> is there an option to "reserve" failed jobs
> without kicking them?

No, but you can copy each job into another place
(in memory, into a database, or into another tube
in beanstalkd) and delete the original.

kr

[Bruno]

I second that. In many situations, we need to expose a global status
of the queues, with opportunity for an administrator to take action on
some failed jobs, or queued jobs.

Of course, beanstalk is a queue manager at first, and should not be
seen as an array of jobs.
In my case, I'm managing process-intensive jobs that require a human
to take action based on a complex technical context.
Ideally, I'd need to get simple lists of JOB ids. Real job data is
stored in a database-table.
What I really need is a simple list of job-id's in a "ready" state,
currently reserved or buried.

Today, I have to reserver-all then release-all to simulate this
behavior. I have no idea of what jobs are being processed.

Thanks!