Closed beeandbo closed 10 years ago
At the time I wrote it, I couldn't get executeAndWait
to work - iirc it's part of the beeswax api but not part of the impala api. I'd certainly accept a pull request that used it, if the tests passed =)
Cool. It seems to pass for me. Perhaps a versioning issue? Impala isn't always the most stable tech. I'm in the middle of a release, but when I get a chance, I'll clean everything up and issue a pull request.
On Thu, Nov 14, 2013 at 7:26 PM, Colin Marc notifications@github.comwrote:
At the time I wrote it, I couldn't get executeAndWait to work - iirc it's part of the beeswax api but not part of the impala api. I'd certainly accept a pull request that used it, if the tests passed =)
— Reply to this email directly or view it on GitHubhttps://github.com/colinmarc/impala-ruby/issues/8#issuecomment-28544773 .
Great, looking forward to it!
This seemed like a good enough idea that I just went ahead and did it - hope you don't mind =)
Not at all :). I'm working hard on Impala latency for smaller queries, and initial tests have show this has helped a lot,. I'm finally able to get queries in the 30-40ms range, which I previously though was not possible with Impala.
On Thu, Nov 14, 2013 at 11:18 PM, Colin Marc notifications@github.comwrote:
This seemed like a good enough idea that I just went ahead and did it - hope you don't mind =)
— Reply to this email directly or view it on GitHubhttps://github.com/colinmarc/impala-ruby/issues/8#issuecomment-28551452 .
I noticed you're using the send_query thrift command, then immediately block until the query is done via a polling loop with a 100ms wait. Is there a reason you do this rather than calling executeAndWait, which according to the thrift docs is a synchronous call? Just wondering if this was an oversite, or an intentional design decision.