drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Parth Chandra <pchan...@maprtech.com>
Subject Re: C++ DrillClient Hanging issue
Date Tue, 14 Oct 2014 20:49:36 GMT
Yes. I think the 1305 fix should go in first.

On Tue, Oct 14, 2014 at 10:28 AM, Norris Lee <norrisl@simba.com> 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: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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message