[
https://issues.apache.org/jira/browse/THRIFT-5327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283819#comment-17283819
]
Paolo Elefante edited comment on THRIFT-5327 at 2/12/21, 4:46 PM:
------------------------------------------------------------------
Hi guys,
I see the problem in the C++ method TSocket::getPeerHost().
In details, getPeerHost invokes the API getnameinfo that unfortunately, in case
of DNS misconfigurations, hangs for several seconds and returns an error that
is ignored. I think this part of code of getPeerHost() can be handled
differently:
{code:java}
char clienthost[NI_MAXHOST];
char clientservice[NI_MAXSERV];
getnameinfo((sockaddr*)addrPtr,
addrLen,
clienthost,
sizeof(clienthost),
clientservice,
sizeof(clientservice),
0);
peerHost_ = clienthost;
{code}
In case getnameinfo returns any error peerHost_ cannot be set. This is the
reason why getOrigin return dirty characters: when the DNS problem happens
(because of Temporary failure in name resolution), peerHost_ is set to the
uninitalized buffer clienthost.
The class TSSLSocket is also affected by this.
BR, Paolo
was (Author: paolo.elefante):
Hi guys,
I see the problem in the C++ method TSocket::getPeerHost().
In details, getPeerHost invokes the API getnameinfo that unfortunately, in case
of DNS misconfigurations, hangs for several seconds and returns an error that
is ignored. I thing this part of code of getPeerHost() can be handled
differently:
{code:java}
char clienthost[NI_MAXHOST];
char clientservice[NI_MAXSERV];
getnameinfo((sockaddr*)addrPtr,
addrLen,
clienthost,
sizeof(clienthost),
clientservice,
sizeof(clientservice),
0);
peerHost_ = clienthost;
{code}
In case getnameinfo returns any error peerHost_ cannot be set.
The class TSSLSocket is also affected by this behavior.
BR, Paolo
> ServerHello is sent with a delay from thrift
> --------------------------------------------
>
> Key: THRIFT-5327
> URL: https://issues.apache.org/jira/browse/THRIFT-5327
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.13.0
> Environment: C++ Application running on linux x86_64
> Reporter: A.Hari Venkata Ramana
> Priority: Major
>
> I have a C++ environment which uses thrift for server. Server is of type
> TThreadPoolServer with TBufferedTransportFactory as transport and
> TBinaryProtocolFactory as protocol. Clients get connected to this server and
> this happens via TLS. We are using thrift server with version 0.13.0 on the
> server end.
>
> In one of the environments where a client using thrift (version 0.10.0), the
> client Hello is sent as part of initial TLS negotiation. We have observed
> that the server Hello is sent after around 25-30 seconds after the client
> Hello is received by the server.
>
> In these cases where delay is observed on server end we are printing the
> client origin details, ie., the server ip of client and the port from which
> it is connecting to the server.
>
> functionXXX(const ::apache::thrift::TConnectionInfo& connInfo){
> std::string origin = connInfo.input->getInputTransport()->*getOrigin*();
> printf("CONNECTED: %s\n", origin.c_str() );
>
> .......}
> In cases where the ServerHello is delayed from thrift, we see the junk
> characters in prints from the above code as shown below:
>
> { Info = "CONNECTED: ����:52089"}
>
> { Info = "CONNECTED: ����:52465"}
> { Info = "CONNECTED: ����:55027"}
> { Info = "CONNECTED: ����:59066"}
> In cases where the IP address of the client is shown as normal characters (as
> shown below) we dont see any delay in the serverHello sent from the thrift
> server and it just takes few milli seconds to send the serverHello back to
> client.
>
> \{ Info = "CONNECTED: 172.30.1.41:46573"}
>
> Looking at the change history we see the following change done in thrift
> 0.13.0:
>
> - [THRIFT-4762](https://issues.apache.org/jira/browse/THRIFT-4762) - cpp:
> TTransport::getOrigin() is now const
>
> Could this be the cause of the delay from the thrift server in sending the
> Server Hello back to clients as part of TLS negotiation?
>
> Any pointers here would be very useful.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
