-
Notifications
You must be signed in to change notification settings - Fork 129
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
RUM-1040 Stop Core Instance #1541
Conversation
Datadog ReportBranch report: ✅ |
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
451d541
to
a768e3e
Compare
Datadog ReportBranch report: ✅ |
a768e3e
to
4774bc5
Compare
9534e0c
to
33373b7
Compare
Datadog ReportBranch report: ✅ 0 Failed, 2545 Passed, 0 Skipped, 25m 10s Wall Time 🔻 Code Coverage Decreases vs Default Branch (6)
|
33373b7
to
bbbe421
Compare
This PR is finally ready for review, it has increased in size due to the added integration tests. |
def do_DELETE(self): | ||
""" | ||
Routes all incoming DELETE requests | ||
""" | ||
self.__route([ | ||
(r"/requests$", self.__DELETE_requests), | ||
]) | ||
|
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'm adding this endpoint to remove recorded requests so we can clear the mock server before restarting the core instance.
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 👌
@@ -39,11 +39,6 @@ private class CompositedURLSessionDelegate: NSObject, URLSessionTaskDelegate, UR | |||
} | |||
} | |||
|
|||
/// An example of instrumenting existing `URLSessionDelegate` with `DDURLSessionDelegate` through inheritance. | |||
private class CustomURLSessionDelegate: NSObject, URLSessionDataDelegate { |
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.
Moving to its own file with internal
accessor for re-use in stop-core-instance test.
bbbe421
to
495c05b
Compare
@@ -489,13 +497,10 @@ public enum Datadog { | |||
#endif | |||
|
|||
internal static func internalFlushAndDeinitialize(instanceName: String = CoreRegistry.defaultInstanceName) { | |||
assert(CoreRegistry.instance(named: instanceName) is DatadogCore, "SDK must be first initialized.") |
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.
no assert anymore?
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 don't remember why I removed it TBH! probably in an attempt to flush before stopping the core. Now, I don't see why we assert initialisation here 🤔
495c05b
to
1f31222
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.
This looks good, can we do some testing that no objects are being leaked when the core instance is stopped. Ideally we want to have memory graph something like
...................
..../ \......
start stop
scope.eventWriteContext { context, writer in | ||
writer.write(value: FeatureMock.Event(event: "should not be sent")) | ||
} | ||
|
||
core.stop() |
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.
question/ This looks flaky ❄️ , doesn't it? If it takes more than "min file age" from writing an event to stopping the core, data will be uploaded. What is the rationale here?
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.
Indeed, I can remove the first EWC. Rationale was to assert that no upload is triggered after stopping the core, even with event in the pipe.
IntegrationTests/IntegrationScenarios/Scenarios/Core/StopCoreScenarioTests.swift
Outdated
Show resolved
Hide resolved
def do_DELETE(self): | ||
""" | ||
Routes all incoming DELETE requests | ||
""" | ||
self.__route([ | ||
(r"/requests$", self.__DELETE_requests), | ||
]) | ||
|
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 👌
I agree with @ganeshnj ☝️ that we must test SDK allocations. However, I don't think the |
27efbdc
to
3324a70
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.
Well done 👌. Great work on fixing the memory profile 💪.
let core = CoreRegistry.unregisterInstance(named: instanceName) as? DatadogCore | ||
core?.stop() |
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.
question/ Why not making stop()
a requirement in DatadogCoreProtocol
? I have no opinion on this (both may be fine), just wondering on what was the rationale.
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.
The stop is only required from high level apis, there is no usage from Features so there no need for making it part of the protocol. The requirement might change in the future tho!
What and why?
Add public interface for stopping core instance of the SDK. Stopping the core will deallocate all Features and their storage & upload units.
How?
In parity with Android, the
stopInstance
static method will stop and unregister all feature of the core. Their storage and upload process will be deallocated so no event-write-context and upload will execute.Note
This change was a good opportunity to streamline flushing mechanism of the core (e.g. #1522). But the number of GDC queues involved in the core and Features made the task very tedious with high risk of introducing flakiness. I believe we should continue decreasing the number of queues, by using exclusion-queue as described in WWDC 2017 - Modernizing Grand Central Dispatch Usage, with clear and efficient queue hierarchy. We should do so after building continuous benchmark to make sure we don't decrease performances.
Review checklist
Custom CI job configuration (optional)
tools/