2016-10-09 15 views
0

私はRxJva 2.0.0-RC3で以下を試しました。リクエストメソッドはバッファリングされたアイテムの数に影響しますか?

Flowable.interval(10, TimeUnit.MILLISECONDS) 
    .doOnNext(System.out::println) 
    .observeOn(Schedulers.computation(), false, 10) 
    .subscribe(new ResourceSubscriber<Long>() { 

     @Override 
     protected void onStart() { 
     request(1); 
     } 

     @Override 
     public void onNext(Long t) { 
     try { 
      Thread.sleep(30); 
     } catch (InterruptedException e) { 
      e.printStackTrace(); 
     } 
     System.out.println("received: " + t); 
     request(1L); 
     } 
     ... 
    }); 

次に、以下の結果が得られました。

0 
1 
2 
3 
received: 0 
4 
5 
6 
received: 1 
7 
8 
9 
received: 2 
received: 3 
io.reactivex.exceptions.MissingBackpressureException: Can't deliver value 10 due to lack of requests 
... 

0、1、2及び3は、それが思わ既に射出されたので、流動性が10発せられたときに緩衝アイテムの数は6であるかもしれないので、流動性が13の周囲に放出するであろう後、私はMissingBackpressureExceptionを得ることが期待要求メソッドはバッファされた項目の数に影響を与えません。

私はRxJava 1.2.0で同様のコードを試しましたが、私は別の結果を得ました。緩衝アイテムの数は18(25を介して8)例外がスローされたかもしれないときにバッファリングアイテムの数が10以上

されるので

... 
20 
21 
received: 6 
22 
23 
24 
received: 7 
25 
rx.exceptions.MissingBackpressureException 
... 

バージョン1.2.0の結果も紛らわしいですそれらは適切な行動ですか? バッファリングされたアイテムの数がバッファサイズを超えたときにMissingBackpressureExceptionがスローされると考えました。

MissingBackpressureExceptionが必要な理由は、待機中のアイテムの数がバッファサイズを超えた直後に、私がflowableまたはobservableを停止したいということです。

これで、システムがビジー状態になってからしばらくお待ちください。

答えて

0

1.xでは、intervalはバックプレッシャを無視します。どちらのバージョンでも、プリフェッチが10の場合、observeOnには16要素の内部バッファが作成されますが、1.x intervalはこのバッファをうっかりオーバーフローします。さらに、observeOnは、プリフェッチ量の75%が配信された後(〜7)、そのソースからさらに要求します。 1.xでは、これは問題ではなく、両端が移動するにつれ、およそ24の要素の後でMBEを取得します。 2.xでは、10の最初の要求が配信されていますが、その間に3回しか消費されないため、observeOnは再要求しないので、すぐにMBEを取得します。

+0

ありがとうございました!さて、私はそのメカニズムを理解しています。しかし、なぜ私はキャッシュの仕組みがこのようなものだろうと思っています。パフォーマンス上の理由ですか? – arching

関連する問題