Hi,
I have been looking into an issue where the native client hangs after
failing to handshake during connection.
We have some boundary conditions where a connection is attempted while
the drill service is starting resulting in handshake failures.
--
DrillClient::connect() ends up ultimately
see inline responses
On Thu, Jun 8, 2017 at 4:47 PM, Ralph Little wrote:
> Hi,
> I have been looking into an issue where the native client hangs after
> failing to handshake during connection.
> We have some boundary conditions where a connection is attempted while the
> drill service is startin
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
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.
Query timeout is an artifact of the time when there was no heartbeat
between Drill clients and the server, so it is possible there is some
unexpec
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
Hi Ralph,
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.
Regarding the other issue with a paused VM, I'm not sure what your VM
setup is. Do you
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
Answers inline ...
On Thu, Jun 22, 2017 at 1:43 PM, Ralph Little wrote:
> 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 re
