drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Little <rlit...@inetco.com>
Subject Re: Native C++ Drill client handshake recovery
Date Tue, 13 Jun 2017 22:18:32 GMT
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


Mime
View raw message