Skip to content
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

Merged

Conversation

mariusc83
Copy link
Member

@mariusc83 mariusc83 commented Apr 24, 2020

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)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Make sure you discussed the feature or bugfix with the maintaining team in an Issue
  • Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

@mariusc83 mariusc83 requested a review from a team as a code owner April 24, 2020 08:37
@mariusc83 mariusc83 self-assigned this Apr 24, 2020
@mariusc83 mariusc83 changed the title RUMM-416 #234 FileReader - fix the concurrency issue RUMM-416 FileReader - fix the concurrency issue Apr 24, 2020

val firstBatch = testedReader.readNextBatch()
val secondBatch = testedReader.readNextBatch()
checkNotNull(firstBatch)
assertThat(secondBatch).isNull()
Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

??

Copy link
Member Author

@mariusc83 mariusc83 Apr 27, 2020

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`(
Copy link
Member

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.

Copy link
Member Author

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.

@mariusc83 mariusc83 force-pushed the mconstantin/rumm-416/filereader-fix-concurrency-issue branch from a2c1121 to b0d3850 Compare April 27, 2020 09:10
@mariusc83 mariusc83 force-pushed the mconstantin/rumm-416/filereader-fix-concurrency-issue branch from b0d3850 to f53601d Compare April 27, 2020 10:46
@mariusc83 mariusc83 merged commit 8a38f05 into dd-rum Apr 27, 2020
@mariusc83 mariusc83 deleted the mconstantin/rumm-416/filereader-fix-concurrency-issue branch April 27, 2020 13:03
@xgouchet xgouchet added this to the 1.5.0 milestone May 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants