* Properly implement multicast closing
This PR defines the behavior of Multicast Flow.
Previously, it could crash if new observers are added to the
multicaster or if it is closed while there is an active
collector. Now, both of these operations complete without
an error. Collecting on a closed multicaster receives 0
values and closes immediately.
Fixes: #45
Test: ChannelManagerTest, MulticastTest
* remove empty line to fix lint error
* improve tests
* Add kotlin plugin to cache module
* Remove custom accessors in StoreDefaults as default values are effectively constant.
* Update JUnit to 4.13 RC2 to enable asserting specific error message on expected exception.
* Remove custom accessors in MemoryPolicy as all values are calculated from constants.
* Remove checkstyle and pmd as the codebase will be 100% Kotlin.
* Fix IDE warning in build.gradle by removing static imports.
* Remove unused guava dependencies.
* Improve StoreDefaults docs.
* Failing test for downstream closing w/o ack
Add test case that fails when a downstream closes w/o acking the message
and indefinitely suspending the stream for other active downstreams
Issue: #41
* add test with buffer
* ack latest message when a new upsteam arrives
Previously, a new downstream would be suspended on the ack of
messages that arrived before it, even when buffer is 0.
This PR changes that behavior such that if there is no buffer,
we ack latest message immediately so that new downstream can
get values instead of waiting for values that it'll never receive
* re-apply ktlint
* Make MemoryPolicy Kotlin friendlier
* Make MemoryPolicy usage more Kotlin like
* Format code in FSReader
* Format code in FSWriter
* Format code in FileSystemRecordPersister
* Format code in FileSystemPersister
* Convert BarCodeReadAllPathResolver to Object instead of Class
* Convert BarCodePathResolver to Object instead of Class
* Fix wrong control flow conversion
* Have ChannelManager delegate to an actor rather then implementing one
* update documentation
* Update multicast/src/main/kotlin/com/dropbox/flow/multicast/ChannelManager.kt
* Clean up ChannelManager's interface to make it easier to add more tests (and add them)
Main changes:
* ~`ChannelManager` no longer inherits from `StoreRealActor` but rather
delegates to one.~ - Moved to followup PR
* messages coming from the upstream were placed under `Message.Dispach`
rather than `Message`. These are the only messages accepted from outside
`ChannelManager`
* `ChannelManager` now only exposes `plusAsign`, `minusAsign` for
adding/removing channels, close for closing and send(msg, Message.Dispatch)
for upstream events
* `SharedFlowProducer` no longer has a back dependency on
`ChannelManager`, rather it accepts a `suspend (Message.Dispatch) ->
Unit`
* `ChannelManager` is now built with the upstream flow rather than a
flow factory. Given that a flow is stateless, passing in a flow that can
be re-consumed seems like the simpler API.
* New `ChannelManager` tests
* make changes to existing test minimal
* revert actor delegation to reduce PR size
* comments
* clean up tests
* Bump travis
* lint
* rename `channelManagerInbox` ->``sendUpsteamMessage`
* Fix multiple collections on Multicast
Multicast implementation had a bug where the returned flow could
not be collected multiple times as it was using the same channel
it created when was called.
This PR changes it to create per collection to avoid this issue.
I've also replaced function with a field as there
is no reason to keep creating a new one, it can be just a flow
Test: MultiplexTest#multipleCollections
Fixes: #26
* remove create function
* Cleanup StoreBuilder interface and add some documentation
* Update store/src/main/java/com/dropbox/android/external/store4/StoreBuilder.kt
Co-Authored-By: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
* A little more docs around persistence
The artifact id `store4`, so the current included example dependency line doesn't locate the library. Changing it to `store4` correctly finds the library in the local repository.
* Update dependencies and clean up unused ones.
* Update okio to 2.4.1 and migrate deprecated APIs to extension functions.
* Update platform and build-tools in travis config.
* add dokka for store module
move key parser to tests
* remove parser exception
* move RealStore and SourceOfTruth to internal
* move cache type to internal
* move Clearable to tests
* move fetcher to tests
* move multiplexer to internal
* move map indexed to internal
* random cleanup.
Fixed a bunch of warnings.
Moved SimplePersisterAsFlowable into tests as it is not used anymore but
FlowTest uses it.
Moved MemoryPolicyBuilder test to kotlin to make DEFAULT_POLICY a const
* massive file migration
Rename pipeline tests into impl tests
This PR fixes a bug in StoreRealActor where we could call onClose
while actor is processing some messages. Now instead we send a token
to close and inside the message handler we close the channel so that
no new messages can arrive after close meanwhile messages that arrived
before that close is handled properly.
Also set version to 4.0.0 and cleaned up some code.
Fixes#55
* remove suspend cache
This PR replaces suspend cahce usages w/ direct guava cache usage.
I think we should also get rid of guava cache.
First of all it is in java so needs to be moved to kotlin at least for
future multi-platform support.
Second, it would be nicer to have something that uses kotlin's time so
that people can provide a scope w/ a delay functionality (like the
TestCoroutineScope) and also test time related stuff. An alternative might
be letting people pass a Timer in the builder
Fixes#41
* remove commented code :/
This PR implements piggybacking in fetch controller which means even if
upstream closes, we never close downstream flows in fetcher multiplexing.
Instead, we keep them around and if a new request comes in, they'll receive
the same data as well or even keep the upstream open.
This is implemented as a feature of multiplexer as it already has all of the
machinery to do such re-distribution of data.
It is a bit questionable behavior for multiplexer but it is already very
specific to our use case so I thought it might be fine to do it there
