RickyMa

As you said https://github.com/apache/incubator-uniffle/pull/1714#issuecomment-2120490454, it could be JVM shutting down which causes `InterruptedException`. I think this [patch](https://github.com/apache/incubator-uniffle/pull/1736) might work, could you please test it?

> By the time `close` is called, all threads are completed. If I'm correct, this is not guaranteed. These are different ExecutorServices.

> Let me rephrase this: By the time `ShuffleWriteClientImpl.unregisterShuffle` returns, all unregister requests completed. This is right. The method is not asychronized.

@EnricoMi Could you help to find out the reason here? I still have no clue. I've encountered this issue again this time: https://github.com/apache/incubator-uniffle/actions/runs/9486586733/job/26141279578?pr=1780

I think they are different. This is caused by calling `ShuffleIndexResult.release`. https://github.com/apache/incubator-uniffle/issues/1818 is caused by calling `ShuffleDataResult.release`.

Could you help to look at this issue too?

I think it is feasible, you can do it. Although setting the internal buffer to null might have a positive impact on GC, this impact is usually minimal.

Could you add some logs in `HadoopShuffleReadHandler.readShuffleIndex` to get more infomation why it returned a freed `ByteBuf` whose size is not `0`? Or maybe this time it's not in `HadoopShuffleReadHandler`...

If you are sure that it is `PooledUnsafeDirectByteBuf`, then it must come from `LocalFileClientReadHandler.readShuffleIndex`. Because we use `PooledByteBufAllocator` to receive responses like `GetLocalShuffleIndexResponse` from Uniffle server. Could you please add...

I didn't see the connection between these two release stacktrace logs, as they seem to be unrelated. The first stack contains `ChannelOutboundBuffer`, so it looks more like it happened during...