Does the problem persist even now, if you try again?

@dmitshur Yes. I tried resetting my gerrit cookie too, but to no avail.

I wonder if there's anything wrong with the CL itself. It's rather large, but it doesn't contain any binaries or anything of the kind. Is there any extra information I could give that would help debug this?

I was able to make it work just now, by forcing git to use chunked mode when speaking HTTP. I set git config http.postBuffer 1024, which resulted in a POST git-receive-pack (chunked) rather than the previous POST git-receive-pack (43272 bytes). The gerrit server seemed to like this more.

Please feel free to close this bug if there is nothing else to discuss.

Perhaps, this might be an issue of git transport, for example, TLS alert protocol handling (usually close_notify) in git transport; GnuTLS or OpenSSL+variants.

Perhaps related - I just had an issue where git-codereview mail -trybot was using an entire CPU core on my laptop. top said it was a process called git-remote-http. The command I was running showed nothing. I rebuilt git-codereview, and now it works fine. It got stuck spinning the CPU three times in a row that I tried, before rebuilding the tool.

@acln0 - It is unclear to me how your workaround solved the issue.

According to the man page (https://git-scm.com/docs/git-config#Documentation/git-config.txt-httppostBuffer)

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

So it seems that git automatically uses chunked encoding if the buffer size is larger than 1MiB. And you further reduced the buffer size to 1KB to force chunked encoding always ? But that will mean, if the default is kept to 1MB, then any POST requests to gerrit of size more than 1KB will fail, which seems a bit unlikely.

Gerrit was having issues lately which have been resolved. Would you be willing to give another try by resetting the postBuffer to its default value ?

It is unclear to me how your workaround solved the issue.

It is unclear to me as well. While searching for "POST git-receive-pack hang" or similar terms, I noticed that people who were reporting such issues had a mix of chunked and non-chunked transfer encodings. I was getting a non-chunked transfer, so I thought I should try forcing a chunked transfer encoding, to see if that solves the hang. Whether it solved it by coincidence or by some other factors, I do not know, but I was able to submit the CL. There is no fundamental theory behind the 1KiB number I used either: I wanted something smaller than the size of my pack, which was 43272 bytes.

Would you be willing to give another try by resetting the postBuffer to its default value ?

I was able to send the large CL I was talking about before, and I don't have another large CL to send right now. All my interactions with Gerrit in the meantime have worked just fine.

@agnivade Sorry for the late response. I know this message isn't very helpful, and I'm sorry about that, but I don't see what other details I can give at this point, or what else I could try. Maybe this bug should be closed for now.

Alright, let's reopen this if it crops up again. Thanks for the update.