Re: Beanstalkd 1.5 .deb package

On Sun, Mar 18, 2012 at 10:20:21PM +0100, Serafeim Zanikolas wrote:
> On Thu, Mar 15, 2012 at 02:12:49AM -0700, Keith Rarick wrote:
> > On Sat, Mar 3, 2012 at 4:05 PM, Serafeim Zanikolas
<serzan@...> wrote:
> > > one of the tests fails
> > 
> > That test (pause-tube) has a race that causes it to fail
> > sometimes, and I neglected to fix it before the release.
> > 
> > The output you posted is consistent with correct beanstalkd
> > behavior.
> 
> FYI uploaded to debian unstable, with the test disabled.

more test failures (on amd64 & kfreebsd-i386 respectively):

On line 47 sh-tests/binlog-sizelimit.sh
  first binlog wrong size
  FAIL: sh-tests/binlog-sizelimit.sh

On line 80 sh-tests/binlog-diskfull-delete.sh
  Second binlog file is missing
  FAIL: sh-tests/binlog-diskfull-delete.sh

these are tests that were previously (prior to 1.5) passing on all
Debian-supported arches.

https://buildd.debian.org/status/package.php?p=beanstalkd

sez

Re: Beanstalkd 1.5 .deb package

On Sun, Apr 1, 2012 at 10:13 AM, Serafeim Zanikolas <serzan@...> wrote:
> more test failures (on amd64 & kfreebsd-i386 respectively):

Thanks!

https://github.com/kr/beanstalkd/issues/108

--

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

NotFound exception in delete() -- is beanstalk thread safe?

Peek at complete list of jobs

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

--

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

Re: NotFound exception in delete() -- is beanstalk thread safe?

Re: Peek at complete list of jobs

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

On Mon, Apr 2, 2012 at 2:46 AM, Jurian Sluiman <jurian@...> wrote:
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "beanstalk-talk" group.
> To post to this group, send email to beanstalk-talk@...
> To unsubscribe from this group, send email to beanstalk-talk+unsubscribe@...
> For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en.
>

--

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

Re: Peek at complete list of jobs

Hi Keith,

On Apr 3, 10:39 am, Keith Rarick <k...@...> 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

--

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

Re: Peek at complete list of jobs

On Tue, Apr 3, 2012 at 3:13 AM, Jurian Sluiman <jurian@...> 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

--

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

Re: Beanstalkd 1.5 .deb package

On Sun, Apr 01, 2012 at 03:20:38PM -0700, Keith Rarick wrote:
> On Sun, Apr 1, 2012 at 10:13 AM, Serafeim Zanikolas
<serzan@...> wrote:
> > more test failures (on amd64 & kfreebsd-i386 respectively):
> 
> Thanks!
> 
> https://github.com/kr/beanstalkd/issues/108

FWIW failing tests that previously ran fine are release-critical in Debian

--

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

Exception Stalker::JobTimeout

Hi guys,

First of all, a big thanks for beanstalk team.
I am using stalker for managing my background jobs.
I have some process which would run for more than 119s.
Those jobs which takes more than 119s are raising "Exception
Stalker::JobTimeout".
I know I can manually specify the ttr like below.

Stalker.enqueue("video.webm", {:id =>  <at> video.id}, {:ttr => 10})

But the problem is, I really don't have any idea how much the time
process would consume. It may take minutes to hours.
The ideal approach is use "touch". I don't find any resources online
on how do the stalker way of touching beanstalkd saying im still
alive.

job "run.query" do |args|
   <at> query_event = QueryEvent.find(args["id"])
   <at> query_event.execute_query!
end

My job looks something like the above. Help is appreciated.

Thanks,
Deepak.

--

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