[ECO-5013] feat: Implement room lifecycle monitoring #94
Conversation
1. Defined standard Emitter interface as per RTE emitter spec 2. Added thread safe impl. for the same in ScopedEmitter class 3. Added private AsyncSubscriber class to process events in the given order 2. Added related unit tests covering all edge cases
sacOO7
force-pushed
the
feature/CHA-RL4-room-monitoring
branch
from
4c60f8b to
a7323c1
Compare
Code Coverage
|
| * Kotlin Emitter interface for supplied value | ||
| * Spec: RTE1 | ||
| */ | ||
| internal interface Emitter<V> { |
There was a problem hiding this comment.
I don’t think we need this, as we’re essentially reinventing Flow here. Additionally, we’re missing some crucial points in the ScopedEmitter implementation. In its current form, listeners will be invoked non-sequentially, which can be misleading.
There was a problem hiding this comment.
I was hoping we could have a discussion about this eventually. I don't think we're trying to reinvent the wheel here, though the implementation might resemble shared or hot flows.
Unlike cold flows, hot flows continue emitting values even if no one is actively collecting them. This can lead to situations where the flow keeps emitting values even when the component is in the background, which could potentially cause memory leaks.
Additionally, the flow API is well-suited for use in coroutine-based functions, as both emit and collect are suspending functions. On the other hand, tryEmit can be used in non-suspending functions (like the channel.on method here), although it's generally not recommended.
Since tryEmit() is not a suspending function, it requires a buffer to store the emitted values until they are processed by subscribers. To make this work, we need to set the buffer size to unlimited, but this can affect performance and slow down other subscribers.
Another challenge is canceling flows, as there’s no guarantee that queued events will be delivered when cancellation occurs.
I'll create a separate thread to dive deeper into this and explore how the Emitter implementation can be leveraged for the existing public API to handle messages and presence events asynchronously on the Dispatchers.Default scope, as opposed to relying on the current blocking subscribers.
1. Updated init method to include setting up ContributorListeners 2. Initialized property contributorStateChangeMonitor using ScopedEmitter to track feature channel state changes
…flag tied to part of atomicCoroutineScope operations
1. Temporarily removed use of transientDetachTimeout since more clarity needed from spec point of view 2. Added room monitoring impl. for each feature channel attach, update, attaching, suspended and failed events 3. Updated release() method to remove all monitoring listeners when room is released
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
TODO's
|
…ation with relevant spec
RoomLifeCycleManager