Closed asmuth closed 12 years ago
That's really quite strange - those lines should always happen together if you're running a single threaded application - it shouldn't be possible to get a race condition. I wonder whether you have multiple threads, each one making calls to the same em-hiredis client?
Yes, I think this is the piece of code:
https://github.com/paulasmuth/fnordmetric/blob/v0.5/lib/fnordmetric/worker.rb#L24
I would either use a separate redis client for the blpop operation (especially if you want to use this redis client in other parts of your code), or call the recursive method after the hincrby. Otherwise your event processing will be blocked by the blpop. Let me know if this helps. However I still don't see why you'd be getting out of sync replies...
Mh, I tried both, but neither helped and that instance of the client isn't used anywhere else. (The blpop is supposed to block, because it pops the next job from the queue). If you like, you can add me on Skype and I'll demonstrate the problem and that the switch of send_command and @defs.push seemingly fixes it. Also, I can't find the reason to issue the command to redis before storing the callback? What am I missing? :)
Hey, I found out, that the "Replies out of sync" only happens, when the call is made from inside a Yajl::Parser.on_parse_complete-callback. I stopped using the stream parser and everything is working fine without the change, so I guess I should close the pull request. Thanks! :)
I got a lot of "Replies out of sync"-errors when running under high load. This fixed it for me.