-
Notifications
You must be signed in to change notification settings - Fork 11
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
Alter how periodic session caching works #51
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #51 +/- ##
=======================================
Coverage 74.67% 74.67%
=======================================
Files 308 308
Lines 10095 10095
Branches 1448 1448
=======================================
Hits 7538 7538
Misses 1982 1982
Partials 575 575
|
Sweet. I was just looking at this today and if we have big session payloads, it could lead to a tonne of GC and lmkd kills once we background! |
embrace-android-sdk/src/main/java/io/embrace/android/embracesdk/session/SessionHandler.kt
Outdated
Show resolved
Hide resolved
embrace-android-sdk/src/main/java/io/embrace/android/embracesdk/session/SessionHandler.kt
Outdated
Show resolved
Hide resolved
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.
LGTM. If need re-start the caching, we should probably just not shutdown the executor.
@bidetofevil I made a few changes based on your comments to use |
500b16e
to
d9f33e4
Compare
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.
Nice. LGTM
d9f33e4
to
ea815e8
Compare
Goal
Embrace periodicially caches sessions on disk to handle the case that a crash might lead to data loss. While this is something we ultimately want to move away from, for now I've refactored the existing implementation so that it handles backpressure more gracefully.
Previously we were using a
ScheduledExecutorService
that executes a runnable at a fixed interval. This works fine for most purposes, but if the device is under severe strain then the executor service is unlikely to keep up, and will have a large queue of jobs to churn through (ironically causing more strain). Historically we had the same problem with ANR data capture.I've therefore refactored the logic so that after each cache a new job is scheduled for the given interval.
Testing
Relied on existing test coverage & manually verified that cached sessions make it through to the dash. I also checked that the interval is more or less the same: