Yes. I think the 1305 fix should go in first. On Tue, Oct 14, 2014 at 10:28 AM, Norris Lee <[email protected]> wrote:
> Yes. Perhaps we should hold off on this until DRILL-1305 is complete and > have whatever fix be dependent on 1305? > > -----Original Message----- > From: Parth Chandra [mailto:[email protected]] > Sent: Tuesday, October 14, 2014 9:46 AM > To: [email protected] > Subject: Re: C++ DrillClient Hanging issue > > Are you trying this on top of the patch for DRILL-1305? > > On Tue, Oct 14, 2014 at 9:39 AM, Norris Lee <[email protected]> wrote: > > > 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 > > > > > >
