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 Mon, 13 Oct 2014 22:51:06 GMT
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