Bug 1006291 - org.eclipse.jgit.errors.MissingObjectException when cloning concurrently
Summary: org.eclipse.jgit.errors.MissingObjectException when cloning concurrently
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER5
: 6.0.0
Assignee: Alexandre Porcelli
QA Contact: Zuzana Krejčová
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-10 11:51 UTC by Zuzana Krejčová
Modified: 2016-08-01 01:08 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-08-06 20:20:06 UTC
Type: Bug
Embargoed:


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

Description Zuzana Krejčová 2013-09-10 11:51:59 UTC
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 23:51:30 UTC
When you say clone concurrently you mean different users cloning the same repository?

Comment 2 Zuzana Krejčová 2013-09-11 08:09:46 UTC
(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 12:25:07 UTC
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):
https://github.com/droolsjbpm/uberfire/blob/master/uberfire-backend/uberfire-backend-server/src/test/java/org/uberfire/backend/server/repositories/RepositoryCreationTest.java


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