|Re: [jgit-dev] Threading and MissingObjectException|
On Thu, Jan 30, 2014 at 11:54 PM, Carlsson, Johannes <Johannes.Carlsson.x@xxxxxxxxxxxxxx> wrote: > Hi Shawn, > > Many thanks for the quick support! I have tested this successfully running both my isolated test case as well as the "real" use case where I originally found the problem. Yay! > Are you interested in a test case? I am not familiar with the test structure for jgit, my local test case requires a git already present, but perhaps I can adapt it to jgit:s structure if you give me some pointers? I am not clear how to write a test around this. The issue was a race condition in multi-threaded code, which is pretty hard to write as a unit test that exactly reproduces the "thread A sleeps while thread B updates" issue you identified. Even if you have a workload that reproduces the bug on an isolated system, that will probably be very flaky in a unit test and just as likely to give false positives as it is false negatives. > > Regards > /Johannes > > -----Original Message----- > From: Shawn Pearce [mailto:spearce@xxxxxxxxxxx] > Sent: den 31 januari 2014 01:32 > To: Carlsson, Johannes > Cc: jgit-dev@xxxxxxxxxxx > Subject: Re: [jgit-dev] Threading and MissingObjectException > > On Wed, Jan 29, 2014 at 9:30 PM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote: >> On Tue, Jan 28, 2014 at 6:25 AM, Carlsson, Johannes >> <Johannes.Carlsson.x@xxxxxxxxxxxxxx> wrote: >>> Hi, >>> I am using jGit for an internal tool here at Sony Mobile. In order to improve performance I started to do some threading. Unfortunately this came with some random MissingObjectException: > ... >>> Now, say we have 2 threads that calls openObjImpl1 on the same instance at the same time. Thread #1 decides to stop for a moment at the comment above. Thread #2 continues execution and will execute tryAgain1() that will return true (packList contained NO_PACKS before this and scanPacks has updated it to a "real" scanned one). The openObjectImpl1 will now return successfully for thread #2. Then thread #1 decides to continue and enters tryAgain1(). The "old" variable will now be assigned with the new packList (since thread #2 parsed it nicely) and isModified will return false and the tryAgain1() will return false which will then cause openObjectImpl1 to fail. >>> >>> I might have missed something, but changing to "return true" (just to test) in tryAgain1() will make my test case pass without any exceptions (I guess that this will have some unwanted performance impact). >> >> I agree with your analysis. There is a bug exactly as described. I >> will try to take a stab at fixing the code tomorrow. > > Untested, but https://git.eclipse.org/r/21362 is today's attempt to fix this.
Back to the top