Re: Re: Native C++ Drill client handshake recovery

2017-06-22 Thread Ralph Little
Hi Parth, Likewise, sorry for my tardy response: Sorry for the late response. For the commented out code, looks like it is wrong. I think we should check to see if m_pError is not null in all cases and return error if it is set to something. I have tried this block added back in and it s

Re: Native C++ Drill client handshake recovery

2017-06-13 Thread Ralph Little
Hi Parth, Looks like the code should not be compiled out unless WIN32_SHUTDOWN_ON_TIMEOUT is defined. No reason for that to be defined on a non Windows platform. At the bottom of the function DrillClientImpl::recvHandshake(), I have: ... #ifdef WIN32_SHUTDOWN_ON_TIMEOUT if (m_pError != N

Re: Native C++ Drill client handshake recovery

2017-06-12 Thread Ralph Little
Hi, Thanks for your response: > The original caller to DrillClient::connect() thinks everything is > hunky-dorey. > Yes, that would be a problem. From what I remember, the recvHandshake call blocks in m_ioservice.run. On return from run, the recvHandshake checks if the error object m_pError is

Native C++ Drill client handshake recovery

2017-06-08 Thread Ralph Little
m_deadlineTimer never triggers as a fall back. Opinions? Cheers, Ralph Little

protobuf version

2017-06-05 Thread Ralph Little
Hi List, I see that Apache Drill is limited to 2.x series for protobuf. I cannot find any reference as to why this is. Could someone explain the dependency restriction? Did something major change in the 3.x release series for protobuf? The only reason I ask is that protobuf 3.3 builds much clean