Possible issue with certain Observables
See original GitHub issueAn issue appeared with the Bluetooth package RxAndroidBle
that might be of interest. The authors have deprecated their own ConnectionSharingAdapter
for sharing BLE connections, and now recommend the use of RxReplayingShare
. This is my understanding:
The package has a method Observable<RxBleConnection> establishConnection( ... )
. This Observable
is somewhat unusual in that it emits a single item (the connection), and never completes. Unsubscribing from it terminates the connection, and if the connection is lost due to a Bluetooth fault, the subscription is canceled with an onError()
exception.
Apparently the issue is that RxReplayingShare
will continue to emit the “stale” cached connection to subscribers even after the original connection is broken. According to the OP, the problem is that ReplayingShare
does not react to finalizations. He describes a fix that might be worth considering. Comments appreciated.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:5
- Comments:10 (4 by maintainers)
I found this issue when using it with RxAndroidBle, where the
RxBleConnection
becomes invalid after theObservable
that emits it is finalized. I agree with you @JakeWharton that always clearing the cached value of theReplayingShare
on finalization may not be a good idea. Doing this fixes theRxBleConnection
issue, but may not be a good general solution.I created a new class
ReplayingUnfinalizedShare
that does clear the cached value on finalization of the shared stream and it fixes theRxBleConnection
issues we found (still, there are race-conditions that I would need to address).For a solution we could have variations of the
ReplayingShare
, like theReplayingUnfinalizedShare
, that clear the cached value each in a unique way. Let me know if it is worth doing this and I could open an issue/PR on your repo.This is the pitfall I fell into: