問題タブ [reactive-streams]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
1652 参照

mysql - Reactive Streams Specification 1.0 がリリースされた後、jdbc 仕様もリアクティブになりますか?

私はakkaストリームでリアクティブストリームプログラミングを学び、使用していました.2年間、async-jdbc-driverまたはreactive-jdbc-driverのライブラリを見つけようとしていました.slick 3.0またはrxjava-jdbc-driverが非同期jdbcを提供することがわかりました. api.

もう 1 つの驚くべき出来事は、昨年 'Reactive Streams Specification V1.0' がリリースされたことです。私の質問は次のとおりです。

  1. このイベントにより、JDBC Expert Group が非同期 JDBC API サポートを設計するきっかけになりますか?
  2. また、MySQL のプロバイダーである Oracle などのデータベースプロバイダー組織は、対応するドライバーを実装する予定はありますか?
  3. これが絶望的である場合、指示、交換、または私が変えることができるもの、またはJDBCレイヤーは反応的である必要はなく、スケールアウトmysqlサーバーで十分ですか?
0 投票する
1 に答える
640 参照

streaming - デフォルトのディスパッチャーを備えたリアクティブカフカ?

反応型カフカコネクタを使用して、Kafka と Akka Streams のプロジェクトに取り組んでいます。Reactive-kafka は独自のディスパッチャ (akka.kafka.default-dispatcher) を使用することがわかりましたが、その場合、デフォルトの akka ディスパッチャを使用すると、すべてが高速になります (reactive-kafka ディスパッチャ ~300 メッセージ/秒、デフォルトのディスパッチャ) ~1300 メッセージ/秒)

デフォルトのディスパッチャーを使用するのが安全かどうか疑問に思います。

前もって感謝します。

0 投票する
0 に答える
498 参照

scala - Akka ストリームは ActorSubscriber の onComplete イベントを無視します

ソースから一定数の要素が流れ込むユースケースがあります。これらの要素が処理され、この場合は ActorSubscriber である Sink があります。すべての要素を送信した後、Source は完了イベントを通知します。このイベントはシンクに伝達され、シンクは onComplete イベントを起動してストリーム ワークフローを閉じます。これはすべて、要素がまだ中間ステップで処理されている間に発生します。

中間ステップが処理されたデータを返したときに処理が完了すると、onComplete イベントがトリガーされたために既に閉じられているため、サブスクライバーは見つかりません。アクター サブスクライバーの onComplete イベントを破棄し、常に開いたままにする方法はありますか。

コード スニペット:

アクター加入者:

スコアリングは処理作業を行います。起こっていることは、3 つの要素を持つソースが完全なイベントをシンクに送信することです。ソースから完了イベントを受信すると、actorSubscriber の onComplete イベントがトリガーされます。処理後、スコアリング エンジンは処理された結果をactorSubscriberに送り返しますが、もはやアクティブではないため、deadLetter メッセージを受け取ります。

0 投票する
2 に答える
121 参照

scala - Akka Reactive Streams は常に 1 メッセージ遅れます

何らかの理由で、私の Akka ストリームは、最初のメッセージを「発行」(?) する前に、常に 2 番目のメッセージを待ちます。

これが私の問題を示すサンプルコードです。

出力が得られます:

私が欲しいもの:

0 投票する
0 に答える
127 参照

playframework - 遊ぶ!Java: Websocket を介してストリームからメッセージをプッシュする

WebSocket を使用して、Kafka ストリームを介して受信したメッセージをクライアントにプッシュしたいと考えています。

私たちの当初の考えは、Play! を使用することでした。HTTP インターフェースを提供するための Java フレームワークと、リアクティブ ストリーム処理のための Akka と Play の Iteratee を介してメッセージをプッシュするための Akka を使用するフレームワークですが、Play では Iteratee api を使用できないようです。ジャバ。これに対する回避策はありますか?