Red Hat Bugzilla – Bug 1006291
org.eclipse.jgit.errors.MissingObjectException when cloning concurrently
Last modified: 2016-07-31 21:08:04 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
When you say clone concurrently you mean different users cloning the same repository?
(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.
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