[infinispan-issues] [JBoss JIRA] (ISPN-3010) Cache GET operation retrieves a Class instance instead of expected type
Sanne Grinovero (JIRA)
jira-events at lists.jboss.org
Wed Oct 2 18:37:02 EDT 2013
[ https://issues.jboss.org/browse/ISPN-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809078#comment-12809078 ]
Sanne Grinovero edited comment on ISPN-3010 at 10/2/13 6:36 PM:
----------------------------------------------------------------
The following is the only Method I could find which is ever storing something in the cache using as Key a _ChunkCacheKey_.
{code}org.infinispan.lucene.impl.InfinispanIndexOutput.storeBufferAsChunk(byte[], int){code}
The following method is technically also writing using the same key type, but it only exists for backwards compatibility with older Lucene versions and in practice this method will never have been invoked in this test:
{code}org.infinispan.lucene.InfinispanDirectory.renameFile(String, String){code}
The object type of the value is a byte array.
How is it possible that any get() operation on the cache is returning an instance of _Class_?
I have no idea, yet that's what the above stacktrace is highlighting. We don't know if it would ever happen only on Windows, we just know that the CI machines which regularly report this failure are running on Windows, but also that these machines are quite slow (AFAIK they are virtual machines) so it could be that it's not related to Windows but rather because of a slowly executing runtime which is triggering some unexpected state in Infinispan.
Note also:
- that the test is in a state of having "just joined" an existing grid when it fails.
- the test was never run on a more recent version of Infinispan as its version is pinned to the one in EAP: you think it might have been resolved already?
was (Author: sannegrinovero):
The following is the only Method I could find which is ever storing something in the cache using as Key a _ChunkCacheKey_.
{code}org.infinispan.lucene.impl.InfinispanIndexOutput.storeBufferAsChunk(byte[], int){code}
The following method is technically also writing using the same key type, but it only exists for backwards compatibility with older Lucene versions and in practice this method will never have been invoked in this test:
{code}
The object type of the value is a byte array.
How is it possible that any get() operation on the cache is returning an instance of _Class_?
I have no idea, yet that's what the above stacktrace is highlighting. We don't know if it would ever happen only on Windows, we just know that the CI machines which regularly report this failure are running on Windows, but also that these machines are quite slow (AFAIK they are virtual machines) so it could be that it's not related to Windows but rather because of a slowly executing runtime which is triggering some unexpected state in Infinispan.
Note also:
- that the test is in a state of having "just joined" an existing grid when it fails.
- the test was never run on a more recent version of Infinispan as its version is pinned to the one in EAP: you think it might have been resolved already?
> Cache GET operation retrieves a Class instance instead of expected type
> -----------------------------------------------------------------------
>
> Key: ISPN-3010
> URL: https://issues.jboss.org/browse/ISPN-3010
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Reporter: Sanne Grinovero
> Assignee: Pedro Ruivo
> Labels: retest, stable_embedded_query
> Fix For: 6.0.0.CR1
>
>
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/hibernate-search-master-windows/org.hibernate$hibernate-search-infinispan/194/testReport/org.hibernate.search.infinispan/StoredIndexTest/testRestartingNode/
> {quote}
> Error Message
> HSEARCH000103: Unable to initialize IndexManager emails
> Stacktrace
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager emails
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:222)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146)
> at org.hibernate.search.event.impl.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:130)
> at org.hibernate.search.hcore.impl.HibernateSearchIntegrator.integrate(HibernateSearchIntegrator.java:83)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:303)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1750)
> at org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:182)
> at org.hibernate.search.infinispan.StoredIndexTest.startNode(StoredIndexTest.java:121)
> at org.hibernate.search.infinispan.StoredIndexTest.testRestartingNode(StoredIndexTest.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to [B
> at org.infinispan.lucene.SingleChunkIndexInput.<init>(SingleChunkIndexInput.java:49)
> at org.infinispan.lucene.InfinispanDirectory.openInput(InfinispanDirectory.java:290)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:620)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:1099)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:155)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 42 more
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the infinispan-issues
mailing list