Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Edoardo Vacchi
    @evacchi
    (rx java 2.x branch)
    dwursteisen
    @dwursteisen

    @samueltardieu

     obs = geoCaches.share();
    withMap = obs.filter(c -> c.withStaticMap()).buffer(5);
    withoutMap = obs.filter(c -> c.withoutStaticMap()).buffer();
    result = withMap.mergeWith(withoutMap);

    Something like this ?

    Samuel Tardieu
    @samueltardieu
    @dwursteisen Will mergeWith prefer withMap over withoutMap?
    Also, I can't filter as easily as the information with/without static maps is not in the geocache object. It requires a disk access, so that would be: geocaches -> (geoCache, hasStaticMaps?) -> cache -> filter…
    (first enrich the geocache with the static maps information to do it only once)
    But the important think is how backpressure and input preference is handled by mergeWith. In Akka streams, there is an explicit mergePreferred which favours one entry over the others.
    dwursteisen
    @dwursteisen
    @samueltardieu : mergeWith will subscribe sequentially I think. So I will first emit items from withMap.
    For the backpressure part, I don't know
    Samuel Tardieu
    @samueltardieu
    @dwursteisen Yes I know, but it won't do what I want: I want the first source to be preferred if elements are available, and the other one to be used if not. The idea is to have one of the source be a priority source. Backpressure is important here, as we have to wait for the subscriber to request elements before looking if the priority source has some to give.
    For example, in my case, the subscriber does network requests, and only a few of them can be done in parallel. As soon as a slot is available because a previous request has terminated, then the subscriber will request a new element from upstream to start a new request. That's when I want to use the priority source if it has an element ready, or the other one otherwise.
    dwursteisen
    @dwursteisen
    hum; ok.
    if elements are available : when do you know it's available ? Have you check switch operators ?
    Samuel Tardieu
    @samueltardieu
    I should not have to know. Look at the definition of mergePreferred in Akka streams: http://doc.akka.io/docs/akka/2.4.2/scala/stream/stages-overview.html#mergepreferred
    When downstream (the subscriber) requests an element, this request is forwarded to the various sources (observables). If several sources have an element ready, then the one from the preferred source is sent to the subscriber (and another one is queried for later). Elements from the non-preferred sources are only sent when no elements from the preferred source are available and the subscriber requests some.
    It's not easy to explain when we are at the boundary of two systems with different vocabularies :-) We have source/observable, flow/operator, sink/subscriber
    dwursteisen
    @dwursteisen
    ok. I see the problem. But I don't know (yet) how to write it using RxJava.
    hum. Your (prefered) Observable should be the first to emit an item, in fact ?
    prefered.mergeWith(other) will (defacto) emit items from prefered as it be subscribed first. It should be pretty closed to your description ? (but the mergefrom Akka can't be done out of the box with Rx, I think, as Rx don't do random subscription order)
    Samuel Tardieu
    @samueltardieu
    I can't know. I go through all the geocaches, and each geocache puts itself into one of the other observable depending on whether or not it has a static map. I don't know where the first geocaches will fit. And since this is a huge geocaches collection, I don't want to go too fast in producing the results as determining whether or not a geocache has a static map requires disk access and consumes battery. So if the user cancels the operation in the middle, I don't want to have wasted too many disk accesses and CPU. That's why I want to follow the subscriber demand.
    Yes, but preferred might require a long time to generate in full if many geocaches do not fit the criterium. So the network downloader (the subscriber) will have to wait, while it could in the meantime download some non-preferred geocaches that we have encountered when going through the list of geocaches.
    For example, let's imagine that you have 1000 caches from 1 to 1000 with the first and the last fullfilling the criterium, the others won't. By using a regular concat, I'll have to go through the list, 1 will get downloaded, 2 to 999 will be put in the non-preferred observable, we will get to 1000 eventually and download it, then we will download 2 to 999. What I would like is download 1, put 2 to 600 aside for example, then the subscriber has a network slot available so it will get 2 because there is no preferred geocache at this time, scanning will continue from 601 to 1000, then 1000 will be handed to the subscriber then 3 to 999.
    Samuel Tardieu
    @samueltardieu
    On the other hand, if geocaches 1 to 998 meet the criteria and 999 and 1000 don't, we will hand 1 to the network downloader, continue to scan 2 to 6 then stop because the downloader has no slot available so it will backpressure, then when it requests another geocache to download it will be handed 2 and we will scan 7 and pause again, etc. So we follow the demand and don't do useless work by analyzing the geocaches in this case, if the user cancels we won't have trashed the disk retrieving useless information.
    dwursteisen
    @dwursteisen
    Have you a test which reproduce the issue ? I don't have the solution, but it's a interesting use case.
    Samuel Tardieu
    @samueltardieu
    Not yet, but I'll have one soon if I write such an operator :-)
    dwursteisen
    @dwursteisen
    (and the test may help to fully understand the issue)
    :D
    Samuel Tardieu
    @samueltardieu
    @dwursteisen I'm out now, but you can look at the test cases at https://github.com/cgeo/cgeo/blob/master/tests/src/cgeo/geocaching/utils/RxUtilsTest.java#L117
    cavemansspa
    @cavemansspa
    these examples https://github.com/ReactiveX/RxGroovy/tree/1.x/src/examples/groovy/rx/lang/groovy/examples were created a while ago. is this still the correct approach to implementing non-blocking Observables -- any recent Rx changes that would approach this differently?
    cavemansspa
    @cavemansspa
    would the new Completable replace the thread based non-blocking Observable in these examples?
    Completable completable1 = Completable.fromAction({ Thread.sleep(5000) println 'hello world'}) .subscribeOn(Schedulers.io());
    fAns1k
    @fAns1k
    hi guys, please help me with this snippet, it looks simple but for some reasone it hasn’t work as expected
    Observable.from(videoStreams)
                            .delay(videoStream -> playlistSubject.startWith((Void) null)
                                    .doOnNext(new Action1<Void>() {
                                        @Override
                                        public void call(Void aVoid) {
                                            Timber.d("Emit delay");
                                        }
                                    }))
    my point is to emit items one by one, to play in media player
    Dorus
    @Dorus
    delay merely delays the current one item untill the inner observable emit. This happens instantly because of startWith.
    fAns1k
    @fAns1k
    i tried to fix it this way =)
    Dorus
    @Dorus
    What's expected?
    fAns1k
    @fAns1k
    i get list of items (e.g. 5) and i start to play first immideately
    others should play after first, etc
    media player gives me event that video is ended, and then i play next one
    Dorus
    @Dorus
    So you need to buffer the items untill the previouse finishes. Try concatMap.
    fAns1k
    @fAns1k
    i cannot interact with player inside the stream
    that’s why i use subject (PublishSubject) to send event to push new item
    Dorus
    @Dorus
    So if i understand you correctly, you have 2 streams, one that emit 5 items and should reemit them 1 at the time, each time another stream emits the previous item is finished playing?
    I'm not even 100% sure if this is an reactive problem.
    fAns1k
    @fAns1k
    i guess it does
    Dorus
    @Dorus
    anyway, you can even use zip. source.zip(playerReady(startWith(ready))).
    fAns1k
    @fAns1k
    ok, will try, thanks for response =)
    Dorus
    @Dorus
    zip will wait for both streams to have emited something.
    We append a start value to playerReady so that it always starts as ready, so the first item from source is emitted.
    fAns1k
    @fAns1k
    yep, it connects one to one from streams
    Dorus
    @Dorus
    Then the next item from source will be forwarded as soon as playerReadyyields again.