Of course, the above seems nuts, eg having to store the jobid's to process later - the consumer should just be able to read all ready state jobs off the queue. Tho please note, I am using the latest Git gub code due to MacOSX 10.5.8 not being able to bind with the current stable release. I "imagine" that as I have beanstalkd running & accepting & removing jobs all ok - I don't have another bug due to watching of queues. Kyle
On Aug 20, 1:16 pm, "voomstudio.com" <[email protected]> wrote: > Hi all, just to confirm the docs - all suggestions welcome. > > I have a seperate process that adds/produces/puts data onto a host > with default 127.0.0.1:11300 config. The data gets put on a defined > tube of notification - all good. > > I have a consumer on a separate process with the same default > 127.0.0.1:11300 config that "watches" this named queue of notification > (ignoring default). The consumer tries to pull/consume jobs using the > "peek-ready" option. So all jobs on this queue in a ready state should > be available to be reserved. > > However, the consumer continues to get "Response not found" errors > with the above setup. So after some playing around, I put & consumed > my messages on the one process, & all worked fine. On reading the docs > I notice in the peek commands **All but the first operate only on the > currently used tube.** > > The peek commands let the client inspect a job in the system. There > are four > variations. All but the first operate only on the currently used tube. > - "peek <id>\r\n" - return job <id>. > - "peek-ready\r\n" - return the next ready job. > - "peek-delayed\r\n" - return the delayed job with the shortest delay > left. > - "peek-buried\r\n" - return the next job in the list of buried jobs. > > So to confirm - even though I am running the same host/port/tube name, > the consumer still does not know about "ready" jobs that have not been > created by it's own instance/process? If this is true, then I will > have to persist the jobId "somewhere" for the consumer to use for > future processing. A step/hop I didn't think I would have to do. Can > this please be confirmed that I have to persist - or am I missing > somehting here? > > And if I do have to persist, what recommendations. At this point I'm > thinking memcache as it's a fast/light key value pair & i don't need > to persist the jobids indefinitely. > > All comments welcome. > Thanks > Kyle --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
