[JBoss JIRA] (ISPN-9411) Shutdown process hangs on same cache each time
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-9411?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-9411:
-------------------------------------
The simplest way to workaround this issue is to set {code}passivation="true"{code} to {code}passivation="false"{code} in your config.
You mentioned that you were having perf issues with load when switching from rocks db to single file store (~1.5s). In that case we should log that as a different JIRA if you are still having that issue.
> Shutdown process hangs on same cache each time
> ----------------------------------------------
>
> Key: ISPN-9411
> URL: https://issues.jboss.org/browse/ISPN-9411
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.4.Final, 9.3.1.Final
> Environment: Linux, cluster with two nodes
> Reporter: Sergey Chernolyas
> Attachments: filestore_931_stack.txt, server_log.txt, server_log_for_infinispan_931_hang.txt, shutdown_10540_931.txt, shutdown_15226_931.txt, shutdown_7181_924.txt, shutdown_7252_924.txt
>
>
> Each time, shutdown process hangs on same cache.
> Configuration of the caches are:
> {code:title=Cache configurations|linenumbers=true|language=XML}
> <distributed-cache name="ACCESSORIES" owners="2" segments="1024" mode="SYNC">
> <state-transfer await-initial-transfer="true" enabled="true" timeout="2400000" chunk-size="2048"/>
> <partition-handling when-split="ALLOW_READ_WRITES" merge-policy="PREFERRED_ALWAYS"/>
> <memory>
> <object size="1000000" strategy="REMOVE"/>
> </memory>
> <indexing index="LOCAL">
> <property name="default.directory_provider">infinispan</property>
> <property name="default.indexmanager">org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="default.worker.execution">async</property>
> <property name="default.index_flush_interval">500</property>
> <property name="default.indexwriter.merge_factor">30</property>
> <property name="default.indexwriter.merge_max_size">1024</property>
> <property name="default.indexwriter.ram_buffer_size">256</property>
> <property name="default.locking_cachename">LuceneIndexesLocking_accessories</property>
> <property name="default.data_cachename">LuceneIndexesData_accessories</property>
> <property name="default.metadata_cachename">LuceneIndexesMetadata_accessories</property>
> </indexing>
> <rocksdb-store preload="true" path="/data/rocksdb/accessories/data">
> <expiration path="/data/rocksdb/accessories/expired"/>
> </rocksdb-store>
> </distributed-cache>
> <distributed-cache name="LuceneIndexesData_accessories">
> <state-transfer await-initial-transfer="true" enabled="true" timeout="2400000" chunk-size="2048"/>
> <partition-handling when-split="ALLOW_READ_WRITES" merge-policy="PREFERRED_ALWAYS"/>
> <rocksdb-store preload="true" fetch-state="true" passivation="true" name="accessories_index_data" path="/data/rocksdb/accessories_index_data/data">
> <expiration path="/data/rocksdb/accessories_index_data/expired"/>
> </rocksdb-store>
> </distributed-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-9486) Hot Rod clear event
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-9486:
-------------------------------------
Summary: Hot Rod clear event
Key: ISPN-9486
URL: https://issues.jboss.org/browse/ISPN-9486
Project: Infinispan
Issue Type: Enhancement
Components: Hot Rod, Server
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
The Hot Rod events don't include a clear event which would be useful to flush client near caches.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-5545) Make lazy near caching more selective
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5545?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-5545:
---------------------------------------
I have extracted the simple part (filtering/converting) to ISPN-9498.
> Make lazy near caching more selective
> -------------------------------------
>
> Key: ISPN-5545
> URL: https://issues.jboss.org/browse/ISPN-5545
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> In the current form, when lazy near caching is enabled, the server sends invalidation messages for any key that has been created, modified or removed.
> This is suboptimal for a couple of reasons:
> 1. First of all, a near cache might only interested in receiving invalidation events for those keys that are currently stored in the near cache. If the near cache is small subset of the entire cache, having such option would vastly reduce the number of events sent to clients. So, there needs to be a way to be able to narrow the events sent from the server to this subset of keys.
> 2. Lazy near caches do not care about created events. If an entry is present in the near cache, it has already been created, so it's only interested in modified and removed events. There needs to be a way to narrow this down too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-9485) RoundRobinBalancingStrategy always starts from server 0
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9485?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9485:
-------------------------------
Status: Open (was: New)
> RoundRobinBalancingStrategy always starts from server 0
> -------------------------------------------------------
>
> Key: ISPN-9485
> URL: https://issues.jboss.org/browse/ISPN-9485
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod
> Affects Versions: 9.4.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.4.0.Final
>
>
> {{RoundRobinBalancingStrategy}} always starts from server 0, and resets back to 0 if a server topology update has less servers. This means if N clients start and immediately add a listener (e.g. for near cache), all N client listeners will be attached to the same server.
> We should pick a random server on every server topology update instead, so that near cache listeners are attached to random servers.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months