I'm using C++ asynchronously thrift for IPC inside my application.
One client of my thrift is connected to the server using T_PROTOCOL_COMPACT protocol using TCompactProtocolFactory (and of course the transport is TAsioTcpConnectServerTransport).
I do see that my client is being connected successfully to the server.
Client side:
2024-01-29 09:23:40,636 INFO [0x7ffff53576c0] ClientEventHandler<Interface> (../../src/ipc/thrift/AsyncThriftClient.tpp:68) 229 - "Function":"onConnect", "Event":"ASYNC_THRIFT_CLIENT_ON_CONNECT", "Message":"Client connects to the server", "ServiceName":"MulpiSvcClient.10.244.22.229", "RemoteEndpoint":"10.244.22.229:23501"
2024-01-29 09:23:40,636 INFO [0x7ffff53576c0] ClientEventHandler<Interface> (../../src/ipc/thrift/AsyncThriftClient.tpp:75) 229 - "Function":"onConnect", "Event":"ASYNC_THRIFT_CLIENT_ON_CONNECT", "Message":"Client was created successfully to the server"
Server side
2024-01-29T09:23:40.636009637Z {"Role": "active", "Severity": "INFO", "Package": "server", "Version" : "1.48-598.2", "File": "ThriftServiceManager.hpp:25", "Logger": "server.api", "Function": "onConnect", Connected local=[::ffff:10.244.22.228]:23501 remote=[::ffff:10.244.22.253]:52436}
But I see that sometimes the call is successful but in most time I get TException thrown.
Thrift: Mon Jan 29 09:22:01 2024 Unhandled exception MISSING_RESULT Exception: 'GetOfdmaCmMerData'
I will add also a screenshot from PCAP file I've captured on the client side.
Is there any reason why this can be happening? Is it because the server side drops the client request or maybe the client didn't waited enough for the server response?
EDIT:
Adding here logs from successful call
2024-01-29T09:47:38.293726795Z {"Severity": "ERROR", "Package": "client", "Version" : "1.0-21", "File": "../../src/external-interfaces/mulpi/clientInterface.cpp", "Line": "272", "Function": "GetOfdmaCmMerData", "Event":"EXT_IFACES_MULPI_GET_OFDMA_CHANNEL_DATA", "Message":"GetOfdmaCmMerData", "Id":"0x1000000", "subId":"0x29", "serverIp":"10.244.22.229", "mdOfdmaCmMerDataFetchSize:":"MdOfdmaCmMerData {
2024-01-29T09:47:38.293762061Z Id: 16777216
2024-01-29T09:47:38.293769181Z SubId: 0
2024-01-29T09:47:38.293773881Z ofdmaCmMerData: OfdmaCmMerData {
2024-01-29T09:47:38.293778161Z mslotsInfo:
2024-01-29T09:47:38.293782125Z Key: 0, Value: MinislotInfo {
2024-01-29T09:47:38.293785868Z index: 0
2024-01-29T09:47:38.293789721Z lowerFreq: 39000000
2024-01-29T09:47:38.293793793Z }
2024-01-29T09:47:38.293797520Z Key: 1, Value: MinislotInfo {
2024-01-29T09:47:38.293801191Z index: 1
2024-01-29T09:47:38.293805018Z lowerFreq: 39400000
2024-01-29T09:47:38.293808412Z }
2024-01-29T09:47:38.293812383Z Key: 2, Value: MinislotInfo {
2024-01-29T09:47:38.293816468Z index: 2
2024-01-29T09:47:38.293820141Z lowerFreq: 39800000
2024-01-29T09:47:38.293823760Z }
...
2024-01-29T09:47:38.302070699Z Key: 170, Value: MinislotInfo {
2024-01-29T09:47:38.302074986Z index: 170
2024-01-29T09:47:38.302079187Z lowerFreq: 107000000
2024-01-29T09:47:38.302083072Z }
2024-01-29T09:47:38.302087105Z mers:
2024-01-29T09:47:38.302091026Z }
SOLVED:
The issue was that the connection was sometimes opened to server with same THRIFT IFACE but with different IP which doesn't have the requested data inside it.