January 2019 - infinispan-issues - Jboss List Archives

[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)

7 years, 2 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)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9894) AbstractRemoteCacheManagerFactory leaks threads

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9894?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9894: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > AbstractRemoteCacheManagerFactory leaks threads > ----------------------------------------------- > > Key: ISPN-9894 > URL: https://issues.jboss.org/browse/ISPN-9894 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1 > > > {{AbstractRemoteCacheManagerFactory}} creates a temporary {{RemoteCacheManager}} in order to load the default Hot Rod client properties, but never stops it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9905) Rest store should retrieve created and lastUsed TS from server

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9905?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9905: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > Rest store should retrieve created and lastUsed TS from server > -------------------------------------------------------------- > > Key: ISPN-9905 > URL: https://issues.jboss.org/browse/ISPN-9905 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, REST > Affects Versions: 10.0.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta1 > > > Currently the rest store simply sets the created and lastUsed entries to the current time of the node loading an entry, instead we should retrieve this value from the server if fetchMetadata is true. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9898) JGroupsTransport leaks channel after initial cluster size timeout

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9898?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9898: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Alpha3) > JGroupsTransport leaks channel after initial cluster size timeout > ----------------------------------------------------------------- > > Key: ISPN-9898 > URL: https://issues.jboss.org/browse/ISPN-9898 > 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 > > > {{JGroupsTransport}} fails during startup if a minimum cluster size is configured and there are not enough nodes. Because the component is in failed, stopping the cache manager does not invoke the stop method and the channel is leaked. > We could catch the exception in {{JGroupsTransport}} and close the channel there, but it would be safer if {{BasicComponentRegistryImpl}} invoked the stop methods for failed components as well. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9480) misleading client side WARN message

by Adrian Nistor (Jira)

[ https://issues.jboss.org/browse/ISPN-9480?page=com.atlassian.jira.plugin.... ] Work on ISPN-9480 started by Adrian Nistor. ------------------------------------------- > misleading client side WARN message > ----------------------------------- > > Key: ISPN-9480 > URL: https://issues.jboss.org/browse/ISPN-9480 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Reporter: Wolf-Dieter Fink > Assignee: Adrian Nistor > Priority: Major > > The client will log warn messages for @Indexed annotations > WARN o.i.p.impl.AnnotatedDescriptorImpl : Encountered and ignored and unknown annotation "Indexed" on <some proto field> > At client side there is no knowledge about indexing annotations. This is normal. > The warning should not issued. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9480) misleading client side WARN message

by Adrian Nistor (Jira)

[ https://issues.jboss.org/browse/ISPN-9480?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9480: -------------------------------- Status: Open (was: New) > misleading client side WARN message > ----------------------------------- > > Key: ISPN-9480 > URL: https://issues.jboss.org/browse/ISPN-9480 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Reporter: Wolf-Dieter Fink > Assignee: Adrian Nistor > Priority: Major > > The client will log warn messages for @Indexed annotations > WARN o.i.p.impl.AnnotatedDescriptorImpl : Encountered and ignored and unknown annotation "Indexed" on <some proto field> > At client side there is no knowledge about indexing annotations. This is normal. > The warning should not issued. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9875) Setup infinispan-operator source tree in jboss-dockerfiles project

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9875?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-9875: --------------------------------------- Assignee: Gustavo Fernandes (was: Vittorio Rigamonti) > Setup infinispan-operator source tree in jboss-dockerfiles project > ------------------------------------------------------------------ > > Key: ISPN-9875 > URL: https://issues.jboss.org/browse/ISPN-9875 > Project: Infinispan > Issue Type: Task > Reporter: Vittorio Rigamonti > Assignee: Gustavo Fernandes > Priority: Major > > Move source code from [here|https://github.com/rigazilla/infinispan-operator/] to [there|https://github.com/jboss-dockerfiles/infinispan-server-operator]. > Do not import vendor folder > Clean up README -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9875) Setup infinispan-operator source tree in jboss-dockerfiles project

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9875?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-9875: ------------------------------------ Git Pull Request: https://github.com/jboss-dockerfiles/infinispan-server-operator/pull/2 (was: https://github.com/jboss-dockerfiles/infinispan-server-operator/pull/1) > Setup infinispan-operator source tree in jboss-dockerfiles project > ------------------------------------------------------------------ > > Key: ISPN-9875 > URL: https://issues.jboss.org/browse/ISPN-9875 > Project: Infinispan > Issue Type: Task > Reporter: Vittorio Rigamonti > Assignee: Gustavo Fernandes > Priority: Major > > Move source code from [here|https://github.com/rigazilla/infinispan-operator/] to [there|https://github.com/jboss-dockerfiles/infinispan-server-operator]. > Do not import vendor folder > Clean up README -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9905) Rest store should retrieve created and lastUsed TS from server

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9905?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9905: ------------------------------- Component/s: Loaders and Stores REST > Rest store should retrieve created and lastUsed TS from server > -------------------------------------------------------------- > > Key: ISPN-9905 > URL: https://issues.jboss.org/browse/ISPN-9905 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, REST > Affects Versions: 10.0.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Alpha3 > > > Currently the rest store simply sets the created and lastUsed entries to the current time of the node loading an entry, instead we should retrieve this value from the server if fetchMetadata is true. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2019