Storm と Spark Streaming は実証されているプラットフォームです。多くのプロダクションの配備があります。それらに比べて、Gearpumpはそれほど実証されておらず、プロダクションの配備もまだありません。しかし、すべてのユースケースをカバーしている単一のプラットフォームはありません。Gearpump has its own +1 points in some unique use cases. 例として、IoTのユースケースに関して、Gearpumpは場所の透過性の機能を使ってトポロジーをエッジデバイスに配備することができるため、簡単だと考えられています。他の例としては、ユーザがアプリケーションをサービスの停止無しにオンラインでアップグレードしたい場合、Gearpumpは動的にその場でDAGの計算を修正できるので、適しているかも知れません。Gearpumpに適しているもっと良いユースケースを知るには、Gearpumpにとって何が良いユースケースかの章を調べてください。

なぜチェックポイントファイルを格納するためにAkka persistenceを使わないのか？

必要な場合には、レコードレベルでは無く、ディスクにチェックポイントファイルを作成します。
独自のチェックポイントファイル形式を持ちます。

高レベルDSLのためにAkkaストリームAPIを考慮したのか？

良いDSLがどのようなものであるかについて多くの候補を調べています。Akka ストリームAPIは候補の一つです。

Actorインタフェースを直接使う代わりに、なぜタスクをラップしたのか？

Unitテストを実施するのがもっと楽です。
流れの制御やメッセージの紛失の検知のように、データの一貫性を確実にするために独自のロジックとメッセージを持ちます。
Gearpumpのインタフェースは急激に発展しています。今のところ、私たちの手を将来のリファクタで縛られないようにもっと強力な機能の公開に保守的でいたいと思っています。それはとても柔軟さを提供するでしょう。

なぜ私のタスクはとてもメッセージが遅延するのか (例えば 10秒)？

タスク内で、ブロックするジョブを実行していないかどうかを調べてください(例えば、sleep、IO)。デフォルトでは、executor内のすべてのタスクはスレッドプールを共有します。他のタスクが実行する機会を得ないまま、ブロックしているタスクが全てのスレッドを使い果たすかもしれません。そのような場合、ユニークなスレッドが各タスクに専念するようにgear.conf内のgearpump.task-dispatcher を "gearpump.single-thread-dispatcher"に設定することができます。

一般的に、パフォーマンスがより良く、しなければならない時にはsingle-thread-dispatcherに切り替わるデフォルトのshare-thread-pool-dispatcher を使うことをお勧めします。

エラー

サービスプロセスが首尾よく起動したとしても、なぜダッシュボードが開けないのか？

デフォルトで、サービスのプロセスはローカルのIPv6 portに紐づけられます。システムの他のプロセスがすでに同じIPv4 portを取っているかも知れません。システムがUnix/Linuxであれば、lsof -i -P | grep -i "Listen" によって調べることができます。