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 have the drillbit running on the paused VM? If you do
then you shouldn't be getting a heartbeat response. If the drill bit is not
on the same VM, then I'm not sure how things are set up for you. Can you
explain?
Parth
On Tue, Jun 13, 2017 at 3:18 PM, Ralph Little <rlit...@inetco.com> wrote:
> 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 != NULL) {
> return static_cast<connectionStatus_t>(m_pError->status);
> }
> #endif // WIN32_SHUTDOWN_ON_TIMEOUT
> startHeartbeatTimer();
>
> return CONN_SUCCESS;
> }
>
> My reading is that if WIN32_SHUTDOWN_ON_TIMEOUT is not defined, then
> m_pError is ignored and the application doesn't know that the handshake
> failed.
> It just goes on to start the heartbeat and returns success. There is no
> connection though.
>
> If the VM is paused, I would expect the heartbeat to fail though.
>>
>
> I see that the Native Client sends the PING and receives a PONG back even
> if the the Hadoop backend VM is paused.
> There is no network activity. I merely assumed that the heartbeat is
> between my app and the JAVA drill process which is alive and well.
> Nevertheless, HDFS is never going to respond to Drill in this situation.
> My knowledge of that side of things is quite a bit less though :(
>
> My current approach is to use the async submitQuery() with a separate
> listener function and add my own timer to wake up the app if it's taking
> too long.
> However, there doesn't seem to be a reasonable way to shutdown the query
> when my timer fires.
> I can call the cancel() function DrillClientQueryResult::cancel() but
> this merely sets a flag.
> If no messages are being received from Drill, I can't see who is going to
> check the flag.
>
> Do you have any suggestions for this?
>
> Regards,
> Ralph
>
>
