問題タブ [infinispan-9]

（クエリセクションの中ほどの質問）

環境:

インフィニスパン 9.13

jgroups を使用したクラスター内の組み込みキャッシュ (ただし、ローカルの basiccache でも同じ動作を確認できます)

単一のファイル ストア

明示的なエビクションもパッシベーションもありません

シナリオ:

特定の頻度 (freq と呼ぶ) で、スレッド (ExecutorService.scheduleAtFixedRate(...) など) は分散キャッシュに put(key, value, freq + buffer, TimeUnit.minutes) を実行します。

そのため、固定された頻度で、以前と同じ値または異なる値を持つ各キーのライフスパン = 頻度 + バッファー (バッファーは安全のためのものであり、頻度よりもはるかに少ない) でエントリがキャッシュに入れられます。

たとえば、挿入は lifespan=freq+buffer で配置できます。

k1、v1

k2、v2

k3、v3

頻度の後、同じ寿命を設定します。

k1、v1

k2、v4 (異なる値)

k3、v3

最大メモリサイズに達していないため、エビクションは発生していません

問題:

単一のファイル ストアでは、キー値が重複しているようで、次の頻度 + バッファの後で十分に確認しています。

したがって、ファイルは単一のファイル store.dat に含まれる可能性があります。

k1,v1

k1、v1、

k2,v2

k2、v3

(これは正確ではありませんが、ファイル ストア内の内容を表したものです)。

get() を使用してプログラムでアクセスすると、常に更新された値または正しい値が返されるため、重複は許容されます (ただし、ほとんどのキーで get を呼び出すことはありません)。

クエリ:

infinispan は単一のファイル store.dat から古い値をクリーンアップして、ファイル ストアが各 put() で無期限に拡大しないようにしますか。これは、各頻度で最後にキー値を追加するか、ファイル内のインプレースを置き換えるためです (一部の Key-Value が重複しており、重複の一部は古く、一部は更新されています)?

このクリーンアップが行われ、重複/古い/期限切れのエントリが多すぎるためにファイルストアが拡大しないことを保証するドキュメント/メカニズムを教えてください。

ドキュメンテーションは、ウェイクアップする失効リーパー スレッドを参照していますが、ここでは、その間隔について明示的に何も渡していません (xml ファイルにエントリがなく、寿命が put() を介してプログラムで設定されているため) - 失効リーパー スレッドがこれを実行している場合デフォルトのウェイクアップ間隔を知り、文書化したいです。

Infinispan のドキュメントからのメモ:

古くて重複したエントリは、予期された動作のようです -

「エビクションを使用しない場合、永続ストアにあるものは基本的にメモリにあるもののコピーです。エビクションを使用する場合、永続ストアにあるものは基本的にメモリにあるもののスーパーセットです (つまり、されたエントリが含まれます)記憶から追い出された）」- http://infinispan.org/docs/stable/user_guide/user_guide.html#cache_loader_behavior_with_passivation_disabled_vs_enabled

「エビクションが構成されておらず、この時間が期限切れになるまで放置すると、Infinispan がエントリを削除していないように見える可能性があります。」- http://infinispan.org/docs/stable/faqs/faqs.html#expiration_does_not_work_what_is_the_problem

これは単一ファイル store.dat の重複をクリーンアップしますか? - 「エントリの有効期限が切れると、ユーザー要求によって再びアクセスされるまで、エントリはデータ コンテナまたはキャッシュ ストアに存在します。有効期限が切れたエントリをチェックして削除する、指定されたミリ秒単位の設定可能な間隔で実行できるオプションの有効期限リーパーもあります。」- Infinispan 9.2 ユーザーガイド

https://developer.jboss.org/message/988346#988346から投稿されたクロス

jboss/infinispan-server:9.4.0.Final ( https://hub.docker.com/r/jboss/infinispan-server ) をレプリケーション付きのスタンドアロン サーバー モードで使用し、クライアントは hotrod 経由で接続します。

これが私たちのgradleファイルからのものです：

各クライアント コード (Java) が hotrod 経由でキャッシュに接続する方法は次のとおりです。

関連するxmlは次のとおりです。

時折、DEBUG レベルで次の例外が発生することがありますが (30 分ごとなど)、ほとんどの場合、期待どおりに動作します。ourCache.get("key") メソッドで 60 秒のタイムアウトまで同期的に待機しているようです。

ただし、その後すぐに操作を再試行すると、正しく機能し、エラーは発生しません。誰かが原因を理解するのを手伝ってくれることを望んでいました。

2019-03-06 07:15:47,668 ERROR: エラーが発生したのは..「アプリ データ メッセージ」です。: java.net.SocketTimeoutException: GetOperation{OUR_CACHE, key=[B0x033E22742D663039..[37], flags=0} が 60000 ミリ秒後にタイムアウトしました

org.infinispan.client.hotrod.exceptions.TransportException: java.net.SocketTimeoutException: GetOperation{OUR_CACHE, key=[B0x033E22742D663039..[37], flags=0} が 60000 ミリ秒後にタイムアウトしました

org.infinispan.client.hotrod.impl.Util.rewrap(Util.java:54) で ~[infinispan-client-hotrod-9.4.0.Final.jar:9.4.0.Final]

org.infinispan.client.hotrod.impl.Util.await(Util.java:27) で ~[infinispan-client-hotrod-9.4.0.Final.jar:9.4.0.Final]

org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:418) で ~[infinispan-client-hotrod-9.4.0.Final.jar:9.4.0.Final]

at ... アプリ jar のスタックトレース

javax.servlet.http.HttpServlet.service(HttpServlet.java:661) で [servlet-api.jar:?]

at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) [servlet-api.jar:?]

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) [catalina.jar:8.5.35] で

org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.35] で

org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat-websocket.jar:8.5.35] で

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:193) [catalina.jar:8.5.35] で

org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.35] で

at ... アプリ jar のスタックトレース

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:193) [catalina.jar:8.5.35] で

org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.35] で

at ... アプリ jar のスタックトレース

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:193) [catalina.jar:8.5.35] で

org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.35] で

org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71) [log4j-web-2.10.0.jar:2.10.0] で

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:193) [catalina.jar:8.5.35] で

org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.35] で

org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:198) [catalina.jar:8.5.35] で

org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [catalina.jar:8.5.35] で

org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493) [catalina.jar:8.5.35] で

org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) [catalina.jar:8.5.35] で

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) [catalina.jar:8.5.35] で

org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) [catalina.jar:8.5.35] で

org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:342) [catalina.jar:8.5.35] で

org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800) [tomcat-coyote.jar:8.5.35] で

org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-coyote.jar:8.5.35] で

org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806) [tomcat-coyote.jar:8.5.35] で

org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) [tomcat-coyote.jar:8.5.35] で

org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-coyote.jar:8.5.35] で

java.util.concurrent.ThreadPoolExecutor.runWorker で (不明なソース) [?:?]

java.util.concurrent.ThreadPoolExecutor$Worker.run (不明なソース) で [?:?]

org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-util.jar:8.5.35] で

java.lang.Thread.run で (不明なソース) [?:?]

原因: java.net.SocketTimeoutException: GetOperation{OUR_CACHE, key=[B0x033E22742D663039..[37], flags=0} が 60000 ミリ秒後にタイムアウトしました

org.infinispan.client.hotrod.impl.operations.HotRodOperation.run(HotRodOperation.java:172) で ~[infinispan-client-hotrod-9.4.0.Final.jar:9.4.0.Final]

io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38) で ~[netty-common-4.1.28.Final.jar:4.1.28.Final]

io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:127) で ~[netty-common-4.1.28.Final.jar:4.1.28.Final]

io.netty.util.concurrent.AbstractEventExecutor.safeExecute (AbstractEventExecutor.java:163) で ~ [netty-common-4.1.28.Final.jar:4.1.28.Final]

io.netty.util.concurrent.SingleThreadEventExecutor.runAllTask​​s (SingleThreadEventExecutor.java:404) で ~ [netty-common-4.1.28.Final.jar:4.1.28.Final]

io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:322) で ~[netty-transport-native-epoll-4.1.28.Final-linux-x86_64.jar:4.1.28.Final]

io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884) で ~[netty-common-4.1.28.Final.jar:4.1.28.Final]

java.util.concurrent.ThreadPoolExecutor.runWorker (不明なソース) で ~[?:?]

java.util.concurrent.ThreadPoolExecutor$Worker.run (不明なソース) で ~[?:?]

... あともう1つ

誰かが根本的な原因と潜在的な修正についてアドバイスしてくれることを望んでいました.

ありがとう、

_プラテック