-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RUMM-416 FileReader - fix the concurrency issue #236
RUMM-416 FileReader - fix the concurrency issue #236
Conversation
|
||
val firstBatch = testedReader.readNextBatch() | ||
val secondBatch = testedReader.readNextBatch() | ||
checkNotNull(firstBatch) | ||
assertThat(secondBatch).isNull() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's already a check on that below (line 110)
|
||
// when | ||
// f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:) don't know what I wanted to say there
@@ -267,21 +269,27 @@ internal abstract class FilePersistenceStrategyTest<T : Any>( | |||
} | |||
|
|||
@Test | |||
fun `read returns null when 1st batch is already sent but file still present`( | |||
fun `reads null when batch already sent but the other thread is still trying to delete this`( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should still keep the old test, and add this one too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well....that's the thing...the first test is not relevant anymore because now we clean the lockedFiles
if the file is removed from the system. I can add a test maybe to return null if the file could not be deleted.
a2c1121
to
b0d3850
Compare
b0d3850
to
f53601d
Compare
What does this PR do?
This PR fixes the concurrency issue we were experiencing in the FileReader. In short this class was using 2 sets to mark files as in progress or sent and only one of these 2 collections was synchronised. Furthermore there was a multithreaded access to this file (from the WorkManager and from the default DataUploadScheduler) and the application was seldom crashing with a ConcurrentModificationAccess.
Motivation
Opened issue #234 on our Github repository
Additional Notes
Anything else we should know when reviewing?
Review checklist (to be filled by reviewers)