-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
client.stats_job() never responds #24
Comments
Some basic questions about the client: Is it watching a set of tubes, including the tube where the job was queued? |
Hi, thanks for the response. Yes it is watching tubes. In fact, there is only 1 tube at the moment, and that's where the job is. Here is the complete source of the worker, it's much like the example in your docs.
BTW: I tried to talk to Beanstalkd over telnet, and that works fine. I can run the same command there, so the server seems to be fine. Update: If I replace the above worker.client.stats_job(...) call with some other command, for instance worker.client.peek_ready(...), that's good. It works fine. But the stats command doesn't respond. |
That's very interesting info! Thank you for the code snippet. I'm going to look into this more deeply tonight. |
Hi OK thanks. Update: The stats_job() method seems to be OK. Running it with another client works as expected. The "bsClient" was created by me and it is using the same tube as the other one.
So either there is something wrong with worker's client, or calling the method from that event handler is the issue? Don't get it. I'll try to look more into this later today. |
Update: Weird. When the bigger code snippet above is executed, there is no warning, info or other event emitted. The only event I get is job.handled, which returns the expected results (job info object). The job itself remains in the ready queue, even after TTR seconds. Somehow execution seems to be halted. I tested this using telnet. If I kill node at this point & restart it, the job gets buried due to an error (the job handler tries to read the websocket). Then, if I add new jobs, the above process is repeated. What am I doing wrong? :) |
One last update: :) I tried to call stats-job() using a separate client rather than the worker's own, just for testing. This works:
The execution continues. The code in the job.handled event handler generates an error (cannot bury job) though, but that's a different issue. So it seems the problems I described above only exist if I try to run stats-job() (or stats) using the worker's client. But of course it doesn't make any sense to create a separate client, the worker already has one. That should be used to execute any command. |
This test passes, so I haven't figured out what the root cause of the problem is yet.
I just wrote a client test that proves to my satisfaction that it isn't a bug in the underlying client: https://github.com/ceejbot/fivebeans/tree/issue-24 I think you're right that it's a worker problem. Now I shall write more tests. And thank you for the code samples-- always helpful! |
OK thx! |
Resuming work on this now (sorry, was a very busy month for me). So! Check out this unit test I added earlier today: https://github.com/ceejbot/fivebeans/blob/master/test/test-worker.js#L343 Note that it's a call to stats_job (two calls, in fact) both made using the worker's client object, called on a job the worker has reserved at the time. Both calls succeed & return correct information about the job in progress. This makes me think it isn't a bug inherent to the worker. The question now is: what's different from your code & my test code? |
I also see this issue. It seems to fail once I try to run things in parallel, and stats_job is called shortly after a job is created. I managed to create a test case:
Output:
Running only one look-up works:
Output:
|
Digging further into this, this will also trigger it:
So if two stats_job run in "parallel" they both fail to respond. From what I can gather it's because they are both added to the response. parseBody then is confused because the expected length doesn't match. |
I was able to reproduce this issue. The problem is exactly what mopagemo described; multiple responses are within a single TCP window and are passed to ResponseHandler.parseBody, but that function can only handle a single response. The pull request fixes this issue and adds a test. |
Issue #24: Handle multiple responses in a single TCP window
Noticing the same issue now. If a client is waiting in a reserve call, then watch, or another command doesn't respond. If reserve is not being executed then watch command works. The below watch commands callback never gets called. The client seems to hang.
work.js
|
Seems as beanstalkd reserve is a blocking call, other commands such as watch/ ignore are hanging. |
I'm new to Beanstalkd. I'm trying to use the stats_job method in a worker, like this:
However, the callback never seem to be called. There is no response at all. And processing of the queue seems to be stuck as well. If I remove this call, everything works fine.
What could be wrong? Thanks in advance! I compiled Beanstalkd from source, I'm on MacOS.
The text was updated successfully, but these errors were encountered: