Bug 1006291

Summary:

org.eclipse.jgit.errors.MissingObjectException when cloning concurrently

Product:

[Retired] JBoss BRMS Platform 6

Reporter:

Zuzana Krejčová <zkrejcov>

Component:

Business Central

Assignee:

Alexandre Porcelli <porcelli>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Zuzana Krejčová <zkrejcov>

Severity:

high

Docs Contact:

Priority:

high

Version:

6.0.0

CC:

etirelli, lpetrovi, zkrejcov

Target Milestone:

ER5

Target Release:

6.0.0

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2014-08-06 20:20:06 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Attachments:

Description	Flags
server log excerpt	none

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