-
Notifications
You must be signed in to change notification settings - Fork 84
RUM-17613: timeseries [3/5] Pass the live RUM context to timeseries pipelines
#3717
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
base: tvaleev/feature/RUM-17613-2-timeseries-schema
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,22 +27,26 @@ internal class Pipeline<T : Any>( | |
| private val buffer: Buffer<T>, | ||
| private val eventFactory: EventFactory<T, *>, | ||
| private val dataWriter: DataWriter<Any>, | ||
| private val rumContext: RumContext, | ||
| private val customAttributes: () -> Map<String, Any?>, | ||
| private val insightsCollector: InsightsCollector = NoOpInsightsCollector() | ||
| ) { | ||
| val intervalMs: Long get() = reader.intervalMs | ||
|
|
||
| @WorkerThread | ||
| fun execute() { | ||
| reader.read()?.let(buffer::add) | ||
| if (buffer.isFull()) drainAndWrite() | ||
| fun execute(rumContext: RumContext) { | ||
| // reader.read() may hit the filesystem (/proc); kept outside the lock so a concurrent | ||
| // flush() waits only for the buffer and never for I/O. | ||
| val dataPoint = reader.read() | ||
| synchronized(this) { | ||
|
Comment on lines
+39
to
+40
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When a session or the RUM feature stops while a scheduled tick is inside Useful? React with 👍 / 👎. |
||
| dataPoint?.let(buffer::add) | ||
| if (buffer.isFull()) drainAndWrite(rumContext) | ||
| } | ||
| } | ||
|
|
||
| @WorkerThread | ||
| fun flush() = drainAndWrite() | ||
| fun flush(rumContext: RumContext) = synchronized(this) { drainAndWrite(rumContext) } | ||
|
|
||
| private fun drainAndWrite() { | ||
| private fun drainAndWrite(rumContext: RumContext) { | ||
| val dataPoints = buffer.drain().ifEmpty { return } | ||
| // Snapshotted here and not at serialization time: serialization runs later on the core | ||
| // context thread, by then the RUM monitor owning those attributes may already be | ||
|
|
||
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.
When a view transition is handled while
reader.read()is in progress, this argument has already captured the previousrumContext; after the read completes,Pipeline.execute()can drain the buffer using that stale view ID even though the new view is active. This contradicts the intended drain-time attribution and can computesession.hasReplayfrom the wrong view, so the live context should be obtained after sampling, at the point the buffer is drained.Useful? React with 👍 / 👎.