git fetch_pack expected ack/nak

[seonguk.baek]

Deal All.

gerri version 2.2.2.1

repo version 1.8.1

git version 1.7.9.4

There is internal server error when repo sync is running like below message. 

You guys have any idea about this problem?

fatal: git fetch_pack: expected ACK/NAK, got 'ERR want d961377db6c6e23a5cbade26723f89123300e97c not valid'

fatal: internal server error

Thanks.

[Shawn Pearce]

Are you fetching over http:// or https:// ?

If so what happened here is the branch your client wanted to fetch was
updated between two HTTP requests and the server is now refusing to
serve your client until your client tries again to find out where the
branch is at. This is a race condition in the HTTP client.

I know this is fixed in the latest JGit builds. Not sure if Gerrit
2.3-rc0 has a new enough JGit to contain the fix.

[david]

Hello. Shawn

We faced same problem sometimes.

I can't understand clearly below comment.

"until your client tries again to find out where the branch is at"

what is this mean exactly?
Please give detail information for this part.

Thanks.

[Shawn Pearce]

The client has to abort its current git fetch or repo sync and start
the command again. :-(

[Shawn Pearce]

On Tue, Apr 3, 2012 at 01:35, seonguk.baek <baeks...@gmail.com> wrote:
> We are fetching over ssh://
>
> Is it possible to cause the same problem?

This error shouldn't be possible over ssh://. I really think you were
talking to an http:// or https:// URL here.

[Lundh, Gustaf]

> fatal: git fetch_pack: expected ACK/NAK, got 'ERR want
> d961377db6c6e23a5cbade26723f89123300e97c not valid'

We are now also seeing this issue and I can confirm that it also happens over the SSH-protocol.

/G

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

[Martin Fick]

On Monday, June 11, 2012 08:17:03 am Lundh, Gustaf wrote:
> > fatal: git fetch_pack: expected ACK/NAK, got 'ERR want
> > d961377db6c6e23a5cbade26723f89123300e97c not valid'
>
> We are now also seeing this issue and I can confirm that
> it also happens over the SSH-protocol.
>
> /G

We are too,

-Martin

> -----Original Message-----
> On Tue, Apr 3, 2012 at 01:35, seonguk.baek
<baeks...@gmail.com> wrote:
> > We are fetching over ssh://
> >
> > Is it possible to cause the same problem?
>
> This error shouldn't be possible over ssh://. I really
> think you were talking to an http:// or https:// URL
> here.

--

Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum

[SeongUk Baek]

Hi guys.

We have the same error still occurs.

The problem is resolved by git gc. But I want to know why occurs the error.

Is there any idea?

Thank you.

[Martin Fick]

See the various missing object discussions...

Including the ongoing "So what does this mean?" thread.

-Martin

On Tuesday, September 24, 2013 06:54:20 pm SeongUk Baek
wrote:

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

[Dave Castagna (Motorola Mobility)]

We are having this issue happen more in the recent past.

We are also using SSH.  We do not use HTTP or HTTPS based syncing.

We are using 2.6.1 so I assume I have the "latest jgit" (as of March 2012 anyway).

We have attempted to move from "git" garbage collection to "gerrit" garbage collection with limited success (a lot of G/C errors and buggy error handling in the G/C code).

The switch over to gerrit g/c is a recent change.

We do nightly server restarts and it still happens.

We have reports that just repeating a "repo sync" will resolve the issue (which seems to corroborate Shawn's original post).

We have had at least one user report this error when using his existing workspace after switching it to a different remote URL so that it points to a different replication slave in our system.  In that case could inconsistencies between the slave he started with and the slave he ended with be a source of the same error?

On Sunday, April 7, 2013 8:38:27 PM UTC-5, Bruce Chiu wrote:

Hi All,

We just have the same issue and "/home/git/review/bin/gerrit.sh restart" fixed it (Temporarily? Same issue occurred a week ago)

We cannot find the root cause of this problem.

[Versions]

Gerrit version: 2.6-rc0

Git version:1.8.1.2

Protocol: SSH

[Error]

fatal: git fetch_pack: expected ACK/NAK, got 'ERR want 60fcc9cacf07af168591f133d53d32a3b6f71d20 not valid'

fatal: internal server error

All of the following commands failed with the same error mentioned above

$ git clone gitsrv:git/the_project

OR

$ git pull

[File /home/git/review_site/logs/error_log]

[2013-04-08 08:48:01,859] ERROR com.google.gerrit.sshd.BaseCommand : Internal server error (user ?????????? account 97) during git-upload-pack 'git/the_project'

org.eclipse.jgit.transport.UploadPackInternalServerErrorException

at org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1040)

at org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:611)

at org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:521)

at com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:57)

at com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:101)

at com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:32)

at com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:70)

at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:429)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

at java.util.concurrent.FutureTask.run(FutureTask.java:138)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)

at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:337)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:662)

Caused by: org.eclipse.jgit.errors.MissingObjectException: Missing blob df977ffde7012f0c1912788ad1e68a4558806d1f

at org.eclipse.jgit.internal.storage.file.WindowCursor.open(WindowCursor.java:149)

at org.eclipse.jgit.internal.storage.pack.PackWriter.writeWholeObjectDeflate(PackWriter.java:1517)

at org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1503)

at org.eclipse.jgit.internal.storage.pack.PackWriter.writeBase(PackWriter.java:1511)

at org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1462)

at org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1440)

at org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:161)

at org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:196)

at org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1428)

at org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1416)

at org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1005)

at org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1179)

at org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1034)

... 16 more

[Dave Castagna (Motorola Mobility)]

I can now confirm that the "gerrit gc" operation is triggering this problem for us.

We stopped doing the "gerrit gc" and went back to "git gc" for a time and the error went away.

Then we returned to "gerrit gc" and within 24 hours users were complaining again of this error.

We could really use a fix for this.  Otherwise we may have to just give up on using "gerrit gc" and live with the sync times the way they already were.

[seonguk.baek]

Thanks for reply!!

We are fetching over ssh://

Is it possible to cause the same problem?

manifest.xml like below.

<manifest>
<remote name="test" review="xxx.xxx.com:8111/xxx" fetch=".."/>
<default remote="test" revision="test_master" />