問題タブ [ignite]

このコードの何が問題になっていますか?? Task Not Serializable から抜け出せない

ここにSTがあります：

オブジェクトを注入する必要がある Startup+Singleton EJB があります。この EJB の PostConstruct メソッドで、Ignite グリッドのリモート キャッシュ イベント リスナーを登録する必要があります。このリスナーの「適用」メソッドは、注入されたオブジェクトのメソッドを呼び出す必要があります。

EventListenerDelegate クラスでは、取得したキャッシュ イベントで最終的に何かを実行する何かをさらに挿入しています。Ignite オブジェクトをこのクラスの RespondToCacheEvent メソッドにも渡す理由は、このメソッド内で cache.remove を発行しているためです。したがって、Ignite オブジェクト自体を渡すと、キャッシュのハンドルをすばやく簡単に取得できます。それが問題ではないことを願っています。

これは問題なくデプロイされます。しかし、キャッシュに何かを入れると、「apply」メソッドの「listenerDelegate.respondToCacheEvent」行で NullPointerException が発生します。これは明らかに、Ignite がリスナーの登録を行った時点で CDI インジェクションが発生していなかったことを意味します。または、問題はまったく別のものである可能性があります。

私がしていることは正しいですか？すべての注入が適切に行われ、remoteListener が登録されていることを確認するには、他にどのようにすればよいでしょうか?

数年前、この gridgain の質問は、マスター (送信側) ノードの Gridgain フェイルオーバー で提起され、対処されました。

今日に早送りします。gridgain 6.2.1 (オープン ソース版) を実行し、gridgain マスターの高可用性を強化しようとしています (ハードウェアまたはマスター プロセスに障害が発生した場合)。高レベルの観点から、定義した継続的なマッパー マネージャーを介して (配布可能な) ジョブをマスター ノードに送信します。

質問に対する以前に受け入れられた回答によると、これは 2011 年には不可能でした。

1. 2015 年に現状は変化しましたか、それとも新しいバージョンの gridgain で利用できる他の戦略はありますか?
2. この機能は、「クラスター グループ」を介して ignite に実装できますか? http://apacheignite.gridgain.org/docs/cluster-groupsを参照してください

ありがとう

私はデータ グリッドを主要な「データベース」として使用しています。Hazelcast と Ignite のクエリ パフォーマンスに大きな違いがあることに気付きました。適切なカスタム シリアライゼーションとインデックスによってデータ グリッドの使用を最適化しましたが、違いは依然として顕著な IMO です。

ここでは誰も質問していないので、今後のすべての参考のために、私自身の質問に答えます。これは抽象的な (学習) 演習ではなく、実際のベンチマークであり、大規模な SaaS システムでのデータ グリッドの使用をモデル化します。主に、並べ替えおよびフィルター処理されたページ分割されたリストを表示します。私は主に、生のフレームワークなしの Hazelcast と Ignite の使用と比較して、ユニバーサル JDBC 風のデータ グリッド アクセス レイヤーがどのくらいのオーバーヘッドを追加するかを知りたいと思っていました。しかし、私はリンゴとリンゴを比較しているので、ここにベンチマークがあります。

ローカルの Ignite ノードに接続して REST 要求を送信しようとしたときにスローされるこの不可解な例外について、誰かが光を当てることができますか?

リクエストは次のようになります: http://127.0.0.1:8080/ignite?cmd=top

Ignite からの応答はありませんが、ログに次のように表示されます。

[GridTcpRestProtocol] 未処理の例外のため NIO セッションを閉じています [cls=class oaiiutil.nio.GridNioException, msg=受信パケットの解析に失敗しました (無効なパケットの開始) [ses=GridSelectorNioSessionImpl [selectorIdx=2, queueSize=0, writeBuf=null, readBuf] =ヌル、リカバリ=ヌル、スーパー=GridNioSessionImpl [locAddr=/127.0.0.1:8080、rmtAddr=/127.0.0.1:64501、createTime=1439344656124、closeTime=0、bytesSent=0、bytesRcvd=278、sndSchedTime=1439344656124、lastSndTime =1439344656124、lastRcvTime=1439344656124、readsPaused=false、filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser [jdkMarshaller=JdkMarshaller []、routerClient=false]、directMode=false]]、accepted=true]]、b=47 ]]

ここで何が問題なのかわかりません。この問題についてウェブを検索しても、あまり成功しませんでした。助けてください。前もって感謝します。

Ignite を使用してこの例外が発生しました

そして私のコード

私のコードの何が問題なのですか

バージョン

版。1.2.0-incubating#20150616-sha1:9fb960ff 2015 Copyright(C) Apache Software Foundation

Gridgain has failover spi mechanism for failure of jobs on nodes. However, we would like to configure a failure mechanism that throws exception even when once of the configured data nodes goes down.

How can we do this?

CacheStoreFactory 実装と CacheStoreSessionListener を使用してキャッシュを作成しています。これらのフィールドで CacheConfiguration を設定してから createCache を呼び出すと、INSTANCE メソッドで次の例外が発生します。

スレッド「メイン」の例外 javax.cache.CacheException: クラス org.apache.ignite.IgniteCheckedException: キャッシュ構成の検証に失敗しました (キャッシュ構成内のすべてのオブジェクトがシリアライズ可能であることを確認してください): LongCache

静的メソッドでは、これは発生しません。これは、例の CacheJdbcStoreExample.java を変更することで簡単に再現できます。これは Ignite 1.30 で発生しています。

メソッドが

CacheStoreAdapter の実装で実行されると、基礎となる DB からロードしたデータは Ignite メモリ キャッシュに自動的に追加されません。それは設計によるものですか？キャッシュへの参照を CacheStoreAdapter に渡して手動で実行できるようにする必要がありput()ますか?