問題タブ [terracotta]
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.
java - クラスタリングのためにehcacheの上にテラコッタが必要ですか?
キャッシュプロバイダーとしてehcacheを使用して、概念実証を行っています。
クラスタリングを提供するためにehcacheとともに、テラコッタサーバーを実行する必要があるとどこかで読んでください。
ehcacheだけでクラスタリングサービスを提供しますか、それともテラコッタも必要ですか?
ありがとう、Venkat
java - Terracotta Ehcache: デバッグ中にサーバーが切断される
デバッガーでアプリケーションに接続してデバッグを開始すると、テラコッタ サーバーへの接続が失われ (?)、テラコッタ サーバー ログに次のメッセージが表示されることがわかりました。
2012-03-30 13:45:06,758 [L2_L1:TCComm メイン セレクター Thread_R (リッスン 0.0.0.0:9510)] 警告 com.tc.net.protocol.transport.ConnectionHealthChecker Impl。DSO サーバー - 127.0.0.1:55112 がロング GC にある可能性があります。最後の ping 応答以降の GC カウント: 1 2012-03-30 13:45:27,761 [L2_L1:TCComm メイン セレクター Thread_R (listen 0.0.0.0:9510)] com.tc.net.protocol.transport.ConnectionHealthChecker Impl を警告します。DSO サーバー - 127.0.0.1:55112 がロング GC にある可能性があります。最後の ping 応答以降の GC カウント: 1 2012-03-30 13:45:31,761 [L2_L1:TCComm メイン セレクター Thread_R (listen 0.0.0.0:9510)] com.tc.net.protocol.transport.ConnectionHealthChecker Impl を警告します。DSO サーバー - 127.0.0.1:55112 がロング GC にある可能性があります。最後の ping 応答以降の GC カウント: 2
...
2012-03-30 13:46:37,768 [L2_L1:TCComm メイン セレクター Thread_R (リッスン 0.0.0.0:9510)] エラー com.tc.net.protocol.transport.ConnectionHealthCheckerImpl。DSO サーバー - 127.0.0.1:55112 がロング GC にある可能性があります。最後の ping 応答以降の GC カウント: 10。しかし、長すぎます。もう再試行はありません 2012-03-30 13:46:38,768 [HealthChecker] INFO com.tc.net.protocol.transport.ConnectionHealthCheckerImpl. DSO サーバー - 127.0.0.1:55112 は DEAD 2012-03-30 13:46:38,768 [HealthChecker] ERROR com.tc.net.protocol.transport.ConnectionHealthCheckerImpl: DSO サーバー - 宣言された接続のデッド接続 ID (1.0b1994ac80f14b7191080bdc3f38582a) アイドル時間2012-03-30 13:46:38,768 [L2_L1:TCWorkerComm # 0_R] 警告 com.tc.net.protocol.transport.ServerMessageTransport - ConnectionID (1.0b1994ac80f14b71 91080bdc3f38582a): CLOSE EVENT: com.tc.net.core. TCConnectionJDK14@5158277: 接続: false、クローズ: true local=127.0.0.1:9510 remote=127.0.0 .1:55112 connect=[Fri Mar 30 13:34:22 BST 2012] idle=2001ms [207584 読み取り、229735 書き込み]。ステータス : 切断されました
...
2012-03-30 13:46:38,799 [L2_L1:TCWorkerComm # 0_R] INFO com.tc.objectserver.persistence.sleepycat.SleepycatPersistor - ChannelID=[1] 2012-03-30 13:46:38,801 のクライアント状態を削除しました[WorkerThread(channel_life_cycle_stage, 0)] INFO com.tc.objectserver.handler.ChannelLifeCycleHandler - : トラン スポーツの切断を受信しました。クライアント ClientID[1] 2012-03-30 13:46:38,801 をシャットダウンしています [WorkerThread(channel_life_cycle_stage, 0)] INFO com.tc.objectserver.persistence.impl.TransactionStoreImpl - shutdownC lient(): DB から txns を削除しています: 0
getWithLoader
これが発生した後、terracotta サーバーが再起動されなくなるまで、キャッシュを使用した操作は応答しません。
質問: どのように修正/再構成できますか? なんらかの (何らかの) 理由でアプリケーションがハングしたり、古くなったりするなどの理由で、本番環境でも発生する可能性があると思います (実際に発生することもあります)。
java - Mybatis の分散キャッシング
Mybatis の分散キャッシュを使用した運用経験のある人はいますか? ehcache/Terracotta に関するいくつかの提案を見ましたが、Terracotta の以前の経験から、Terracotta には近づかないようにしました (構成して実行し続けるのは複雑です)。Hazelcast は興味深い可能性のようです。Mybatis で分散キャッシュとして使用しようとした人はいますか?
私たちのアプリには比較的大きなデータベース (1 TB) があるため、適切にスケーリングできるソリューションが必要です。
ehcache - terracotta で hibernate 分散型 ehcache をセットアップする際のセッション ファクトリの問題
Terracotta を使用して分散環境で EHCache をセットアップしようとしています。ここで、アプリケーション サーバーと Terracotta サーバーを接続でき、Terracotta 開発者コンソールでレプリケートされたオブジェクトを表示できます。
ただし、アプリケーションサーバーでは、アプリケーションの残りの部分は適切に実行されていますが、継続的に次の例外メッセージが表示されます:
こんにちは、この例外メッセージが表示される理由と解決方法を教えていただける方がいらっしゃいましたら、よろしくお願いいたします。また、休止状態アプリケーション用にテラコッタをセットアップするための包括的なチュートリアルがあると助かります。
ここで [CacheByAmitNode8081] は、アプリケーション サーバーで定義したキャッシュ ノードの名前です。
spring - Terracottaを使用したehcacheを介したHibernateの第2レベルのキャッシュ-キャッシュしていませんか?
この春/休止状態のプロジェクトがあり、ehcacheとテラコッタを介して休止状態に第2レベルのキャッシュを追加しようとしています。すべてが正常にプラグインされているようです。テラコッタコンソールで、キャッシュしようとしているエンティティのエントリを確認することもできます。しかし、統計とDBからのログに基づくと、何もキャッシュされていません。
負荷ヒット率は0%で、負荷統計も0です。私が間違っているのは何ですか?
これが私がしたことです。Mavenを介して必要なjarファイルを追加しました。
2次キャッシュを有効にするためにHibernateプロパティを変更しました
テストエンティティに@Cacheアノテーションを追加しました
これが私の非常に単純なehcache.xmlです(同じ結果でエンティティのキャッシュエントリを設定しようとしました)
テラコッタサーバーを起動してテストコードを実行した後
私のログには、発生してはならない100のSQLが表示されます。また、ヒット率は0%と表示されます。
これが私のテストの実行中のテラコッタコンソールからのスクリーンショットです。
これを機能させるために必要な最後のピースは何ですか?
tomcat - 春のセキュリティを備えた Terracotta DSO は、SessionRegistryImpl.java に対して NotSerializableException をスローします。
私たちのアプリケーション スタックは、Tomcat 7 内で実行される hibernate/spring/spring security/JSF です。
オープン ソースの Terracotta 3.6.2 をダウンロードしてインストールしました。
Terracotta DSO を構成したいと考えています。Spring Security SessionRegistryImpl.java を使用して、ログインしているユーザーのセッション情報を取得していますが、このクラスはシリアル化できないため、セッションはシリアル化できなくなります。
次のドキュメントに従いました
http://terracotta.org/documentation/web-sessions/installation-guide http://terracotta.org/documentation/terracotta-dso/dso-install http://docs.terracotta.org/confluence/display/docs/構成+ガイド+および+リファレンス
アプリケーションには次のjarがあります
私は次のTIMを持っています
org.springframework.security.core.session.SessionRegistryImpl の java.io.NotSerializableException を常に取得しています
この場合、Terracotta DSO でクラスターを構成することは可能ですか?
tc-config.xml
ehcache.xml
java - アプリ サーバー クラスタリングと Terracotta の比較
「クラスタリング」という用語は、GlassFish のようなアプリケーション サーバーや Terracotta で使用されているのを聞いたことがあります。また、アプリケーション サーバーと組み合わせて使用する場合、および Terracotta と組み合わせて使用する場合に、クラスタリングという言葉が何を意味するかを理解しようとしています。
私の理解は次のとおりです。
GlassFish サーバーがクラスター化されている場合、複数の物理/仮想マシンがあり、それぞれが GlassFish の個別のインスタンスを実行する独自の JRE/JVM を持っていることを意味します。ただし、それらはクラスター化されているため、すべて管理サーバー (「DAS」) を介して通信し、それらすべてに同じアプリがデプロイされます。それらは単一のアプリケーション サーバーであるかのように (エンド ユーザーに対して) 効果的に機能しますが、負荷分散、フェイルオーバー/冗長性、およびスケーラビリティがミックスに追加されています。
Terracotta は基本的に、異なる物理/仮想マシンで実行されている複数の JVM を単一の JVM であるかのように動作させる製品です。
したがって、私の理解が正しければ、次のことが暗示されます。
- ロード バランシングとフェールオーバー トレランスが必要な場合は、アプリ サーバーをクラスター化します。
- 特定の JVM が小さすぎてアプリケーションを含めることができず、より多くの「馬力」が必要な場合は、Terracotta を使用します。
- したがって、技術的には、たとえば 5 つのサーバー インスタンスの GlassFish クラスタがあるとします。これら 5 つのインスタンスのそれぞれは、実際には Terracotta インスタンスの配列/クラスターである可能性があります。つまり、各 GlassFish サーバー インスタンスは、実際には、複数のマシン自体の JVM 全体に存在する GlassFish インスタンスです。
これらの主張/仮定のいずれかが真実でない場合は、訂正してください! 私がベースから外れてしまい、クラスタリングやテラコッタの目的そのものを明らかに理解していない場合は、正しい方向に向けてください!
https - https の EhCache terracottaConfig url
Terracota サーバー アレイを使用して、セキュリティで保護された環境 (HTTPS など) を使用できますか?
次のように ehcache.xml ファイルを構成しようとしました。
しかし、それはエラーのままです。
可能であれば、これを行う方法は何ですか?
java - Hazelcast のスケジュールされたジョブ (Quartz サポート?)
テラコッタの人たちにとって不公平であることは知っていますが、クラスター化された環境でスケジュールされたジョブを使用するためにHazelcastを使用しようとした人はいますか?
私がイメージできる最も単純な実装は、次のアーキテクチャです。
- 1 つのサーバーのみが Quartz 構成を起動するようにするためのグローバル Hazelcast ロック。
- 実際のタスクを DistributedTask として実行します。(これは後で行うことができます。現時点では、重いスケジュールされたタスクが DistributedTask のトリガーを処理する必要があります)
- ロックを保持しているサーバーがダウンするとすぐに、別のサーバーがロックを取得します。
テラコッタのものを常に開いて開発環境全体の面倒を必要としないため、これはすでにヘーゼルキャストを持っている人にとって大きな利点になると思います.
今のところ、Quartz トリガーの実行を担当するノードを 1 つだけ作成する最も単純なソリューションをコーディングしました。私は Cron のようなトリガーしか使用しないので、負荷の高いトリガー タスク用に DistributedTasks を作成するように注意すれば、許容できる解決策になる可能性があります。
これを実現する org.springframework.scheduling.quartz.SchedulerFactoryBean 拡張機能は次のとおりです。
私が何か大きなものを見逃しているかどうか、そしてこれができるかどうか教えてください.
2 つのファイルを github に追加しました。RAMJobStore 拡張機能は次のとおりです。
Spring SchedulerFactoryBean 拡張機能は次のとおりです。
algorithm - TerracottaJobStoreを使用してQuartz-Schedulerでどのノードジョブが実行されるかを知る方法は?
terracotteJobStoreをQuartz-Schedulerにバインドしました
terracotteJobStoreは、どのノードでどのジョブを実行する必要があるかをどのように判断できますか?
terracotteJobStoreでのノード選択に使用するアルゴリズムはどれですか?