Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] MissingObjectException, why does that happen?

Hi Shawn,

Thanks for an elaborate explanation. It did give me some ideas where to look.

The filesystem resides on an EBS volume mounted on an Amazon EC2 instance and should be quite fast so I don't think that is the cause. It's more likely that we somehow reference a commit that no longer exists. I can see how that could happen since we store the commit ID in a place external to the repository and sometimes recreate clones from scratch.

Regards,
Thomas Hallgren

On 02/16/2012 08:36 PM, Shawn Pearce wrote:
On Thu, Feb 16, 2012 at 07:27, Thomas Hallgren<thomas@xxxxxxx>  wrote:
I'm trying to find the diff between and old commit and the current HEAD. My
method works well but sometimes I get a MissingObjectException when I
resolve the old tree:

org.eclipse.jgit.errors.MissingObjectException: Missing unknown
31631c381870df87e496fc9ae5bdd624c2931621
    at org.eclipse.jgit.storage.file.WindowCursor.open(WindowCursor.java:125)
    at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:228)
    at org.eclipse.jgit.revwalk.RevWalk.parseAny(RevWalk.java:811)
    at org.eclipse.jgit.lib.Repository.parseSimple(Repository.java:585)
    at org.eclipse.jgit.lib.Repository.resolve(Repository.java:389)
    at org.eclipse.jgit.lib.Repository.resolve(Repository.java:376)

The object I try to resolve is assembled as:

  fullCommitID + "^{tree}"

I'm not sure what I'm doing wrong. Any hints on what to look for would be
greatly appreciated.
This happens if the object doesn't exist, or if the object exists but
the caches inside of JGit are stale and JGit didn't notice new loose
objects or new pack files being present.

Normally JGit looks at the packs it knows about, then the loose
objects, then does a stat on the $GIT_DIR/objects/pack directory to
see if packs have been added since the last time it looked. If the
mtime isn't different, it throws this exception because it can't find
the object anywhere.

We try to avoid a race condition on the filesystem mtime not advancing
"quickly enough" during rapid edits by requiring two separate scans of
the pack directory to come up with identical results, separated by
some number of seconds (5?) with the same mtime. This should work.
Unless there is something weird going on that we haven't accounted
for.
What filesystem is the repository stored on? Is it NFS? SMB? A local filesystem?
The filesystem is an EBS volume mounted on an Amazon EC2 instance.

- thomas


Back to the top