[JBoss JIRA] (ISPN-4855) IndexManager start failed
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4855?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-4855 at 11/21/14 2:14 PM:
-----------------------------------------------------------------
[~rvansa] did you see this still happening after ISPN-4807 ?
was (Author: sannegrinovero):
[~rvansa] did you see this still happening after ISPN-4876 ?
> IndexManager start failed
> -------------------------
>
> Key: ISPN-4855
> URL: https://issues.jboss.org/browse/ISPN-4855
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 7.0.0.CR1
> Reporter: Radim Vansa
>
> I have experienced this exception that caused the cacheManager startup to fail:
> Note that this was in library mode, though hotrod client was on the classpath.
> {code}
> org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'org.infinispan.query.remote.indexing.ProtobufValueWrapper'
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:260)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:513)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:482)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:91)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:369)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:208)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:126)
> at org.infinispan.query.impl.LifecycleManager.getSearchFactory(LifecycleManager.java:261)
> at org.infinispan.query.impl.LifecycleManager.cacheStarting(LifecycleManager.java:103)
> at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:762)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:584)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:539)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:416)
> at org.radargun.service.InfinispanEmbeddedService.startCaches(InfinispanEmbeddedService.java:111)
> at org.radargun.service.Infinispan51EmbeddedService.startCaches(Infinispan51EmbeddedService.java:95)
> at org.radargun.service.InfinispanLifecycle.start(InfinispanLifecycle.java:45)
> at org.radargun.service.InfinispanKillableLifecycle.start(InfinispanKillableLifecycle.java:47)
> at org.radargun.stages.lifecycle.LifecycleHelper.start(LifecycleHelper.java:57)
> at org.radargun.stages.lifecycle.ServiceStartStage.executeOnSlave(ServiceStartStage.java:76)
> at org.radargun.SlaveBase.scenarioLoop(SlaveBase.java:84)
> at org.radargun.SlaveBase$ScenarioRunner.run(SlaveBase.java:140)
> Caused by: java.lang.NullPointerException
> at org.infinispan.lucene.readlocks.DistributedSegmentReadLocker.deleteOrReleaseReadLock(DistributedSegmentReadLocker.java:73)
> at org.infinispan.lucene.impl.DirectoryImplementor.deleteFile(DirectoryImplementor.java:65)
> at org.infinispan.lucene.impl.DirectoryLuceneV4.deleteFile(DirectoryLuceneV4.java:64)
> at org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:595)
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:249)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:781)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:146)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:73)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:90)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:256)
> ... 22 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4980) Leaking not shut down cache manager cause VM crash on JDK6 and skipping tests
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4980?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-4980:
----------------------------------
Assignee: Adrian Nistor
> Leaking not shut down cache manager cause VM crash on JDK6 and skipping tests
> -----------------------------------------------------------------------------
>
> Key: ISPN-4980
> URL: https://issues.jboss.org/browse/ISPN-4980
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core, Test Suite - Query
> Affects Versions: 7.0.0.Final
> Environment: consistently failing with JDK6 (very rare occurences with JDK7)
> Reporter: Tomas Sykora
> Assignee: Adrian Nistor
> Labels: test
>
> Please, see linked Bugzilla for more infromation, it also contains links for console outputs from CI jobs and other information we were able to gather.
> Just very briefly, 2 most important meesages:
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!! (testng-ProtobufWrapperIndexingTest) Exiting because ProtobufWrapperIndexingTest has NOT shut down all the cache managers it has started !!!!!!!
> !!!!!! (testng-ProtobufWrapperIndexingTest) See allocation stacktrace to find out where still-running cacheManager (org.infinispan.manager.DefaultCacheManager@1e601e6@Address:null) was created: !!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.14.1:test (default-test) on project infinispan-server-hotrod: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.14.1:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
> Occuring in:
> [INFO] Building Infinispan Remote Query Server
> [INFO] Building Infinispan Hot Rod Server
> [INFO] Building Infinispan JPA CacheStore
> modules
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4980) Leaking not shut down cache manager cause VM crash on JDK6 and skipping tests
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4980?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-4980:
----------------------------------
Status: Open (was: New)
> Leaking not shut down cache manager cause VM crash on JDK6 and skipping tests
> -----------------------------------------------------------------------------
>
> Key: ISPN-4980
> URL: https://issues.jboss.org/browse/ISPN-4980
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core, Test Suite - Query
> Affects Versions: 7.0.0.Final
> Environment: consistently failing with JDK6 (very rare occurences with JDK7)
> Reporter: Tomas Sykora
> Labels: test
>
> Please, see linked Bugzilla for more infromation, it also contains links for console outputs from CI jobs and other information we were able to gather.
> Just very briefly, 2 most important meesages:
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!! (testng-ProtobufWrapperIndexingTest) Exiting because ProtobufWrapperIndexingTest has NOT shut down all the cache managers it has started !!!!!!!
> !!!!!! (testng-ProtobufWrapperIndexingTest) See allocation stacktrace to find out where still-running cacheManager (org.infinispan.manager.DefaultCacheManager@1e601e6@Address:null) was created: !!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.14.1:test (default-test) on project infinispan-server-hotrod: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.14.1:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
> Occuring in:
> [INFO] Building Infinispan Remote Query Server
> [INFO] Building Infinispan Hot Rod Server
> [INFO] Building Infinispan JPA CacheStore
> modules
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4497) Race condition in LocalLockMergingSegmentReadLocker results in file content being deleted
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4497?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4497:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1166865
> Race condition in LocalLockMergingSegmentReadLocker results in file content being deleted
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-4497
> URL: https://issues.jboss.org/browse/ISPN-4497
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.6.Final
> Reporter: Anuj Shah
> Assignee: Sanne Grinovero
> Fix For: 7.0.0.Alpha5
>
>
> There is a race condition in LocalLockMergingSegmentReadLocker which can lead to more calls delete on the underlying DistributedSegmentReadLocker which results in the file being removed from the caches.
> This happens with three or more threads acquiring and releasing locks on the same file simultaneously:
> # Thread 1 (T1) acquires a lock and creates a {{LocalReadLock}}, call it L1 - the underlying lock is acquired
> # T2 starts to acquire and holds a reference to L1
> # T3 starts to acquire and holds a reference to L1
> # T1 releases - L1 at this stage only has value of 1 - so the underlying lock is released, and L1 is removed from the map
> # T2 continues - finds L1 with value 0 and acquires the underlying lock
> # T3 continues - increments L1 value to 2
> # T2 releases - creates a new {{LocalReadLock}}, L2 - this has zero value so the underlying lock is released, and L2 is removed from the map
> # T3 releases - creates a new {{LocalReadLock}}, L3 - this has zero value so the underlying lock is released, and L3 is removed from the map
> # The final step triggers a real file delete as underlying lock is released one too many times
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4710) DistributedSegmentReadLocker should be allowed to skip ReadLocks on small files
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4710?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4710:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1166865
> DistributedSegmentReadLocker should be allowed to skip ReadLocks on small files
> -------------------------------------------------------------------------------
>
> Key: ISPN-4710
> URL: https://issues.jboss.org/browse/ISPN-4710
> Project: Infinispan
> Issue Type: Enhancement
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.CR1
>
>
> Both of these methods:
> - {{org.infinispan.lucene.readlocks.DistributedSegmentReadLocker.deleteOrReleaseReadLock(String)}}
> - {{org.infinispan.lucene.readlocks.DistributedSegmentReadLocker.realFileDelete(FileReadLockKey, AdvancedCache<Object, Integer>, AdvancedCache<?, ?>, AdvancedCache<?, ?>, boolean)}}
> Are performing a lot of unnecessary operations - potentially on synchronous clustered caches - as we know in advance that files which are not being chunked don't need a read lock, and are not being chunked in smaller pieces (which affects how we delete things).
> The determining factor between the two styles is defined in:
> {{org.infinispan.lucene.impl.DirectoryLuceneV4.openInput(String, IOContext)}}
> {code} @Override
> public IndexInput openInput(final String name, final IOContext context) throws IOException {
> final IndexInputContext indexInputContext = impl.openInput(name);
> if ( indexInputContext.readLocks == null ) {
> return new SingleChunkIndexInput(indexInputContext);
> }
> else {
> return new InfinispanIndexInput(indexInputContext);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months