Nope, did not solve the issue. As expected, submitQuery modified m_pendingRequests once it was released from processQueryResult, before it hits this chunk of code. An alternative is to use the query state returned from the drillbit. If it is COMPLETED or CANCELLED, then do not call getNextResult(). With the DRILL-1305 patch, m_pendingRequests is decremented only when the query state returned from the drillbit is COMPLETED or CANCELLED, so it is only at this point when submitQuery would consider calling getNextResult().
-----Original Message----- From: Parth Chandra [mailto:[email protected]] Sent: Monday, October 13, 2014 3:51 PM To: [email protected] Subject: Re: C++ DrillClient Hanging issue In handleRead try { boost::lock_guard<boost::mutex> lock(this->m_dcMutex); if(m_pendingRequests!=0){ getNextResult(); } return; } instead of the current if(m_pendingRequests!=0){ boost::lock_guard<boost::mutex> lock(this->m_dcMutex); getNextResult(); } The above block occurs more than once in handle read. Might also want to protect m_pendingRequests in handleQryError On Mon, Oct 13, 2014 at 3:27 PM, Norris Lee <[email protected]> wrote: > Hi, > > Currently the C++ client uses a variable, pendingRequests, to > determine whether submitQuery or handleRead should call getNextResult. > PendingRequests is incremented when a query is submitted (in > submitQuery) and decrements when a query is completed or cancelled (in > processQueryResult, which is called by handleRead). SubmitQuery will > call getNextResult if pendingRequests is 0. Occasionally we have an > issue with the C++ Drill Client where it hangs when a query is > submitted just after pendingRequests is decremented in > processQueryResult but before handleRead checks it. At this point > submitQuery thinks pendingRequests is 0 so it calls getNextResult. > Also, since a query is submitted, pendingRequests is incremented. > HandleRead then checks the value for pendingRequests, which is now 1, > so it also calls getNextResult. With both threads calling > getNextResult, the client ends up hanging. (And for whatever reason, > we end up getting a handshake response from the server, followed by a > null QueryResult/QueryHandle response, and finally a handshake request, all > from the server). > Any tips/suggestions to resolve this issue? > > Norris >
