Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[HOLD for 4.1] Queue class prototype #347
From what I can see so far, yes, I like what you're doing. And thanks for jumping in on this!
Before going much farther, though, could you sketch out some rough docs explaining it's use? It can be fleshed out more later, but I'm trying to get an idea of how you would recommend setting up listeners, etc.
Looking forward to this!
It doesn't have to be great docs. I can help with that later. Just trying to picture how you intend it to be used.…
Sent from my iPhone
On Jan 2, 2017, at 8:22 AM, noldor (takekoshi) ***@***.***> wrote: Thank you very much. I will try write docs. But I'm not good at English (it's harder than coding for me), so please give me some time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
I wrote functions I think the queue interface should have. Could you check it?
This queue interface will be aware of RabbitMQ. There are 4 components.
There are multiple Consumers listening to same Queue, however, each message is processed by just one Consumer. It will not process twice.
If error raise, message will get back to same queue and will be retried. Retry count is limited. If retry count is over, the message will be deleted.
Sometimes, Consumer job fails repeatedly (e.g. when the mail server is temporary unavailable, etc...).
retry count limit
When a job that always fails retry forever, the queue is full of such jobs.
Retry count is passed to the callback function.
rejecting a job by Consumer
When a error arises, job will be retried automatically. Also we can retry a job manually.
endless loop on Consumer's job
When a job fall into a endless loop, it seems that the job is processing forever from the point of view of the Queue. The job will be neither success nor failure.
On the Database Handler nobody can decide whether a job is processing or not, so the handler regards a job taking more than 300 sec as failure and retry it.
return without waiting after fetching a message
Normally, a request via a browser should response ASAP. So
waiting when there are no messages
If a job works as background job, the job should wait for a messages when there are no messages.
Thank you for taking time.
@noldor No worries. Just checking to see if you were still interested in working on this, and it sounds like you are. Good to hear! And I completely understand being busy. I've had a bit of that myself a month ago where I didn't get to touch it.
Thanks for responding, and looking forward to getting to play with this a bit !