Start impala with the following stress timeouts (the same as those in test_exchange_delays):
Do a join where 0 rows will be exchanged:
When the data-stream-sender sends 0 rows, it sends it with params.row_batch.num_rows=0 and params.eos=true.
The receiver hits the following case:
It ultimately times out from FindRecvrOrWait() after datastream_sender_timeout_ms.
Due to stress_datastream_recvr_delay_ms, the exchange node is Prepare()'d even later.
Although this is a testing flag, this behavior is reasonable to expect in a real world setting under heavy stress, since the stress_datastream_recvr_delay_ms flag was added into testing after some users experienced nodes receiving data from DataStreamSenders and timing out after datastream_sender_timeout_ms, and before the ExchangeNodes were created. Thus, the CloseSender() function is called before the exchange node is created.
After stress_datastream_recvr_delay_ms, the ExchangeNode is created and it calls CreateRecvr().
Then ExchangeNode::Open() calls DataStreamRecvr::CreateMerger() which makes a few threads wait on DataStreamRecvr::SenderQueue::GetBatch().
However, since the DataStreamSender has already received the timeout error from earlier, the receiver threads in GetBatch() will wait indefinitely until the query is cancelled by the user.