Bug 1006291 - org.eclipse.jgit.errors.MissingObjectException when cloning concurrently
org.eclipse.jgit.errors.MissingObjectException when cloning concurrently
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
high Severity high
: ER5
: 6.0.0
Assigned To: Alexandre Porcelli
Zuzana Krejčová
Depends On:
  Show dependency treegraph
Reported: 2013-09-10 07:51 EDT by Zuzana Krejčová
Modified: 2016-07-31 21:08 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:20:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
server log excerpt (7.44 KB, text/x-log)
2013-09-10 07:51 EDT, Zuzana Krejčová
no flags Details

  None (edit)
Description Zuzana Krejčová 2013-09-10 07:51:59 EDT
Created attachment 795966 [details]
server log excerpt

Description of problem:
When cloning two repositories at the same time, you often get 

java.lang.RuntimeException: org.eclipse.jgit.errors.MissingObjectException: Missing commit <HEAD commit>
at org.kie.commons.java.nio.fs.jgit.util.JGitUtil.buildVersionAttributes(JGitUtil.java:606)
at org.eclipse.jgit.api.LogCommand.add(LogCommand.java:172)
at org.kie.commons.java.nio.fs.jgit.util.JGitUtil.buildVersionAttributes(JGitUtil.java:566)

The easiest way to reproduce this is by starting a clean installation with demo playgrounds enabled.
The repositories are cloned, but an error stack trace appears in the server log.

The root cause is that after cloning, some indexing takes place. This uses the HEAD commit of a git repo. This commit object is looked up in an object database, before it is used. It seems the contents of the object db change between these two events (in case of concurrent cloning).
See http://download.eclipse.org/jgit/docs/latest/apidocs/org/eclipse/jgit/api/LogCommand.html#add(org.eclipse.jgit.lib.AnyObjectId)
While jgit seems to expect to be working with only one repository at a time, we force it to work with two at the same time.

Version-Release number of selected component (if applicable):
BPMS 6.0 ER2
Comment 1 Alexandre Porcelli 2013-09-10 19:51:30 EDT
When you say clone concurrently you mean different users cloning the same repository?
Comment 2 Zuzana Krejčová 2013-09-11 04:09:46 EDT
(In reply to Alexandre Porcelli from comment #1)
> When you say clone concurrently you mean different users cloning the same
> repository?

The same repository probably wouldn't cause problems. What I mean is two users cloning different repositories at the same time. Or one user doing two REST calls for cloning a repository too close together. Or you can look at how the product clones the two playground repositories at the start - there's some Batch..something class, I don't remember correctly - but on a clean installation, with playground repositories enabled, those two are cloned pretty much at the same time as well.

When two different repositories are cloned at the same time, what seems to happen is this:

1. You clone both repositories, A and B.
2. You start indexing them.
3. Some kind of object database is keeping tabs on the repository you're using. Right now it's a repository A.
4. You ask it about HEAD commit for repository A and get back some reference to it.
5. You ask it about HEAD commit for repository B and get back some reference to it. For this, the object database has to switch to the repository B at some time, forgetting all about repository A in the process.
6. Now holding the HEAD commit reference for A, you tell jgit to do something with it - but jgit, via the object database, works with the B repository, so it cannot find this A repository HEAD commit.
7. It tells you so in the exception.

To me, it seems that jgit is designed to work with only one repository at a time. So BR/PMS should make sure it really does work with only one repository at a time.. or something.
Comment 6 Alexandre Porcelli 2013-10-31 08:25:07 EDT
I've tried to reproduce this issue, but seems that with recent vfs optimizations this issues seems to be fixed. I've tried to reproduce using an unit test and after executing it several times I never got any error.

unit test (disabled by default, as it needs network resources):

Note You need to log in before you can comment on or make changes to this bug.