Azurite icon indicating copy to clipboard operation
Azurite copied to clipboard

unexptected TCP RST from azurite side

Open Slach opened this issue 2 years ago • 3 comments

Which service(blob, file, queue, table) does this issue concern?

blob

Which version of the Azurite was used?

latest docker image

Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)

I created reproducible docker-compose https://gist.github.com/Slach/043c85f759d4422a75fceab6dccb1f8d

What problem was encountered?

TCP RST after make client requests image image

Steps to reproduce the issue?

git clone https://gist.github.com/Slach/043c85f759d4422a75fceab6dccb1f8d
./reproduce.sh

Have you found a mitigation/solution?

No

also look details https://github.com/ClickHouse/ClickHouse/issues/52088

Slach avatar Jul 13 '23 15:07 Slach

@Slach Thanks for raising this issue!

Would you please share the Azurite debug log for this issue? And please point out in which step of reproduce.sh does this issue repro?

Besides that, just to confirm this kind of issue not happen on product Azure?

blueww avatar Jul 17 '23 10:07 blueww

I've experienced this issue as well in a different context. The debug log shows nothing, because the connection is immediately terminated by the RST. It happens immediately after the client connects. I can't reproduce it on MacOS but it happens easily on Linux.

parshimers avatar Aug 15 '23 21:08 parshimers

@parshimers

From the above wireshark screenshot, it looks the RST is expected, since: There are 4 requests in the screenshot, the first request from Azurite to client has flag "FIN", means the connection is being torn down, and the 2nd request send from client to Azurite has flag "ACK" means agree to terminate the connection, so the 4th request is RST.

The problem looks is on why the 1st request send FIN. But we don't see the whole connection in the screenshot, so can't get the reason. Could you please send the wireshark trace file of the whole request (please use test data, don't include any confidential data in the network trace.)

Besides that, since you can't repro the issue in MacOS, do you use the same Azurite docker image version on linux and macOS? (Docker image with version latest might be cached in local. IF so you might can clearup the local cached Azurite latest docker image, and try again to make sure you use latest docker image.)

As you can't repro on MacOS but can repro on Linux (I assume you use same docker image), it look not be an Azurite code issue, but something related with OS or test environment.

Besides that, does the issue happen randomly, how frequently? If you add some retry logic on storage client side, can it workaround this issue?

blueww avatar Aug 16 '23 08:08 blueww