drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norris Lee <norr...@simba.com>
Subject RE: C++ DrillClient Hanging issue
Date Tue, 14 Oct 2014 17:28:29 GMT
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:pchandra@maprtech.com] 
Sent: Tuesday, October 14, 2014 9:46 AM
To: drill-dev@incubator.apache.org
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 <norrisl@simba.com> 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:pchandra@maprtech.com]
> Sent: Monday, October 13, 2014 3:51 PM
> To: drill-dev@incubator.apache.org
> 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 <norrisl@simba.com> 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
> >
>
Mime
View raw message