[
https://issues.apache.org/jira/browse/OAK-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6314:
-------------------------------
Attachment: OAK-6314.testing.patch
Ok, so, while I can now wait nicely for blocking queue to wrap up (using
multiple marker blobs) - but it seems there's another issue. Here's the flow
how things happen:
# Multiple commits add blobs to a blocking queue
# Each commit submits a runnable if one is not already submitted (hence only
one submit at a time) - this runnable flushes data from blocking queue to a
file (in append mode)
# On a call to purge blobs, currently written file gets unset (hence subsequent
flushes would create a new one). This is synchronized call, so this steps won't
intermix with step2 over the same file
If last flush of blocking queue stuff (step2) and reading of file (step3)
happen very quickly then step3 doesn't quite get all the contents of the file
:-/ (the last flush of data that's written gets lost)
I've added quite a few logs in [^OAK-6314.testing.patch] and what I mean above
shows up as something like:
{noformat}
....
03:20:57.313 DEBUG [pool-1-thread-3] ActiveDeletedBlobCollectorFactory.java:332
NumLines before: 1994
03:20:57.315 DEBUG [pool-1-thread-3] ActiveDeletedBlobCollectorFactory.java:338
NumLines after: 2001
03:20:57.315 DEBUG [pool-1-thread-3] ActiveDeletedBlobCollectorFactory.java:343
Flushed 7 blobs to blobs-0.txt
03:20:57.315 INFO [main] ActiveDeletedBlobCollectorFactory.java:237 Couldn't
read last checked blob timestamp (file not found)
03:20:57.349 DEBUG [main] ActiveDeletedBlobCollectorFactory.java:171 Purging
blobs from target/junit1898475240830020643/b/blobs-0.txt
03:20:57.382 INFO [main] ActiveDeletedBlobCollectorFactory.java:230 Deleted
1994 blobs contained in 3988 chunks
...
{noformat}
{{pool-1-thread-3}} is step2 in action. {{main}} is step3. The attached patch
has a {{Thread.sleep(500)}} before purging - that sleep makes the failure go
away.
I was assuming a write followed by read of a file (property closed and both
threads strictly in order) would show up consistent content of the file..
apparently, that's not the case ...
Btw, if we don't delete the files for which blobs have been deleted (although
unknown to purger, it didn't quite got to read the whole data)... then the test
passes (because next round of purge picks up the file again and gets the data.
> ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently
> for a few users
> ---------------------------------------------------------------------------------------------
>
> Key: OAK-6314
> URL: https://issues.apache.org/jira/browse/OAK-6314
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Affects Versions: 1.7.1
> Reporter: Vikas Saurabh
> Assignee: Vikas Saurabh
> Priority: Minor
> Fix For: 1.8, 1.7.2
>
> Attachments: OAK-6314.testing.patch, test.zip
>
>
> As mentioned in oak-1.7.1 vote thread \[0],
> ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently.
> /cc [~tmueller], [~alex.parvulescu],
> \[0]:
> https://lists.apache.org/thread.html/5b0493c8ccf0dff486a14564d88ccf2baedc84922507ad7a39b07122@%3Coak-dev.jackrabbit.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
