RUMM-2700: Use event write context in WebView Logs#1121
Conversation
Codecov Report
@@ Coverage Diff @@
## feature/sdkv2 #1121 +/- ##
=================================================
+ Coverage 82.43% 82.52% +0.09%
=================================================
Files 348 347 -1
Lines 11380 11355 -25
Branches 1911 1912 +1
=================================================
- Hits 9380 9370 -10
+ Misses 1419 1412 -7
+ Partials 581 573 -8
|
| offset = timeProvider.getServerOffsetMillis() | ||
| offsets[viewId] = offset | ||
| offset = datadogContext.time.serverTimeOffsetMs | ||
| synchronized(offsets) { offsets[viewId] = offset } |
There was a problem hiding this comment.
why do you use synchronized block here ?
There was a problem hiding this comment.
because offsets field can be accessed from the different threads (it gets called from EWC, which can be invoked on the different worker threads), so we need to make the work with this field thread-safe.
The work happens on the worker thread anyway, so synchronisation penalty is not important.
There was a problem hiding this comment.
Yeah, I had that one before but then looked under the hood and noticed that Android uses a SingleThreadExecutor for the JS bridge, I tested it also and made sure we only have one thread there.
There was a problem hiding this comment.
I see the reason now actually with the new architecture, good point.
| try { | ||
| val viewId = offsets.entries.first() | ||
| offsets.remove(viewId.key) | ||
| synchronized(offsets) { |
4 participants
What does this PR do?
This change brings usage of event write context (EWC) to the WebView Logs feature. The approach is similar to what was done before in #1117, #1106, #1103, etc.
There is one non-related change though: in
WebViewLogEventConsumerthe order of event processing is changed: now it is first checked for the proper type, then mapped instead of the opposite (otherwise we may map events which are not going to be written).Review checklist (to be filled by reviewers)