January 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9849) Server should allocate less when looking up the cache

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9849?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9849: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > Server should allocate less when looking up the cache > ----------------------------------------------------- > > Key: ISPN-9849 > URL: https://issues.jboss.org/browse/ISPN-9849 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: performance > Fix For: 10.0.0.Beta1 > > > * A composed String key is allocated to look up a decorated cache > * Another composed String key is allocated to look up the {{CacheInfo}} object for that decorated cache. We could keep this map and remove the decorated caches map. > * Reads decorate the cache with {{SKIP_STATISTICS}}, allocating a {{Flag[]}} and a {{DecoratedCache}} per request. I'd like to remove this wrapping, even if updating the statistics slows things down a bit, because without statistics there's no way to find the hit ratio of the cache. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9850) State transfer enabled attribute is overridden by store fetch-state attribute

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9850?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9850: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > State transfer enabled attribute is overridden by store fetch-state attribute > ----------------------------------------------------------------------------- > > Key: ISPN-9850 > URL: https://issues.jboss.org/browse/ISPN-9850 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1 > > > The decision whether to request state is made based on {{(configuration.clustering().stateTransfer().fetchInMemoryState() || configuration.persistence().fetchPersistentState())}}. In the XML {{fetchInMemoryState}} is {{<state-transfer enabled=X/>}}, {{fetchPersistentState}} is {{<store fetch-state=X/>}}. > We should rename {{fetchInMemoryState}} to match the XML and to indicate that it enables/disables all state transfer, and stores should not be allowed to fetch state if state transfer was disabled in the state transfer configuration. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9859) Upgrade to Netty 4.1.32.Final and Netty tcnative 2.0.20

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9859?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9859: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > Upgrade to Netty 4.1.32.Final and Netty tcnative 2.0.20 > ------------------------------------------------------- > > Key: ISPN-9859 > URL: https://issues.jboss.org/browse/ISPN-9859 > Project: Infinispan > Issue Type: Component Upgrade > Components: Hot Rod, REST, Security, Server > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.6.Final > > > In order to fix an NPE with IBM JDK we need to upgrade to Netty 4.1.32.Final and Netty tcnative 2.0.20.Final > https://github.com/netty/netty/issues/8170 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9882) JdbcStringBasedStore leaks threads

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9882?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9882: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > JdbcStringBasedStore leaks threads > ---------------------------------- > > Key: ISPN-9882 > URL: https://issues.jboss.org/browse/ISPN-9882 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1 > > > When stopping, {{JdbcStringBasedStore}} only stops the connection factory if it implements {{ManagedConnectionFactory}}. {{PooledConnectionFactory}} doesn't implement it, so Agroal connection pools are not closed and leak threads. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9863) Testsuite leaks threads

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9863?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9863: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > Testsuite leaks threads > ----------------------- > > Key: ISPN-9863 > URL: https://issues.jboss.org/browse/ISPN-9863 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Beta1 > > > Some hotrod-client tests do not stop their {{RemoteCacheManager}} instances. This was fine before ISPN-8619, but the Netty-based client starts event loop threads and we need to stop them. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9884) SoftIndexFileStore.destroy leaks threads

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9884?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9884: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > SoftIndexFileStore.destroy leaks threads > ---------------------------------------- > > Key: ISPN-9884 > URL: https://issues.jboss.org/browse/ISPN-9884 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1 > > > {{SoftIndexFileStore.destroy()}} doesn't call {{Index.stopOperations()}}, so the index threads keep on running. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9886) Use UFC_NB and MFC_NB in default embedded configurations

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9886?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9886: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > Use UFC_NB and MFC_NB in default embedded configurations > -------------------------------------------------------- > > Key: ISPN-9886 > URL: https://issues.jboss.org/browse/ISPN-9886 > Project: Infinispan > Issue Type: Task > Components: Configuration > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.6.Final > > > Once properly configured, UFC_NB and MFC_NB are just as fast as their blocking siblings (ISPN-9828). We should use the non-blocking variants everywhere to simplify configuration. > We should include UFC_NB even in the TCP configuration, to prevent async messages from overwhelming the receiver (JGRP-2301). -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9887) Upgrade to JGroups 4.0.16.Final

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9887?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9887: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > Upgrade to JGroups 4.0.16.Final > ------------------------------- > > Key: ISPN-9887 > URL: https://issues.jboss.org/browse/ISPN-9887 > Project: Infinispan > Issue Type: Component Upgrade > Components: Core > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.6.Final > > > [Release notes|http://belaban.blogspot.com/2019/01/jgroups-4016.html] > The most interesting fix for us is JGRP-2324, which might help with the cluster stability when two nodes leave in rapid succession (although JGRP-2293 is not fixed yet). -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9890) Query doesn't stop properly after index data loss

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9890?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9890: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > Query doesn't stop properly after index data loss > ------------------------------------------------- > > Key: ISPN-9890 > URL: https://issues.jboss.org/browse/ISPN-9890 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1 > > > When index cache entries are lost (e.g. because a test didn't override {{clearContent()}} to clear the indexes properly before stopping the manager), the query module throws an exception during stop: > {noformat} > 18:41:36,669 ERROR (testng-Test) [ComponentRegistry] ISPN000538: Error stopping module org.infinispan.query.impl.LifecycleManager:___defaultcache > java.lang.AssertionError: file _0.cfe does not exist; files=[] > at org.apache.lucene.index.IndexWriter.filesExist(IndexWriter.java:4338) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09] > at org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4409) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09] > at org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2865) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09] > at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2970) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09] > at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1082) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09] > at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1125) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09] > at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.closeIndexWriter(IndexWriterHolder.java:173) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.closeIndexWriter(AbstractWorkspaceImpl.java:109) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.shutDownNow(AbstractWorkspaceImpl.java:104) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.backend.impl.lucene.LuceneBackendResources.shutdown(LuceneBackendResources.java:103) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.backend.impl.lucene.WorkspaceHolder.close(WorkspaceHolder.java:68) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.util.impl.Closer.push(Closer.java:92) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.util.impl.Closer.push(Closer.java:107) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.indexes.spi.DirectoryBasedIndexManager.destroy(DirectoryBasedIndexManager.java:76) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.indexes.impl.IndexManagerGroupHolder.close(IndexManagerGroupHolder.java:80) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.util.impl.Closer.push(Closer.java:92) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.util.impl.Closer.pushAll(Closer.java:120) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.indexes.impl.IndexManagerHolder.stop(IndexManagerHolder.java:186) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.util.impl.Closer.push(Closer.java:92) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.util.impl.Closer.push(Closer.java:107) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.engine.impl.ImmutableSearchFactory.close(ImmutableSearchFactory.java:268) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.hibernate.search.engine.impl.MutableSearchFactory.close(MutableSearchFactory.java:133) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final] > at org.infinispan.query.impl.LifecycleManager.cacheStopping(LifecycleManager.java:411) ~[classes/:?] > at org.infinispan.factories.ComponentRegistry.preStop(ComponentRegistry.java:200) [classes/:?] > at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:373) [classes/:?] > at org.infinispan.cache.impl.CacheImpl.performImmediateShutdown(CacheImpl.java:1159) [classes/:?] > at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:1124) [classes/:?] > at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520) [classes/:?] > at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520) [classes/:?] > at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520) [classes/:?] > at org.infinispan.manager.DefaultCacheManager.terminate(DefaultCacheManager.java:734) [classes/:?] > at org.infinispan.manager.DefaultCacheManager.stopCaches(DefaultCacheManager.java:786) [classes/:?] > at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:762) [classes/:?] > at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:847) [test-classes/:?] > at org.infinispan.test.MultipleCacheManagersTest.clearContent(MultipleCacheManagersTest.java:158) [test-classes/:?] > {noformat} > When this exception appears, all but the first {{SyncWorkProcessor}} threads are leaked. Interesting enough, in {{ClusteredCachePerfIspnTest}} the exception is only thrown when stopping node B -- node A stops cleanly and all {{SyncWorkProcessor}} threads are stopped. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9897) ClusterExecutor shouldn't rely on JGroupsTransport

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9897?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9897: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > ClusterExecutor shouldn't rely on JGroupsTransport > -------------------------------------------------- > > Key: ISPN-9897 > URL: https://issues.jboss.org/browse/ISPN-9897 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Beta1 > > > Cluster Executor currently uses transport to send messages. However the initial implementation used JGroupsTransport. Either this was a mistake at the time or enough classes have been refactored that this is no longer needed and just the Transport class can be used instead. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2019