[JBoss JIRA] (ISPN-4674) Hot Rod client receives ArrayIndexOutOfBoundsException and InvalidResponseException when topology changes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4674?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4674:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1134184
> Hot Rod client receives ArrayIndexOutOfBoundsException and InvalidResponseException when topology changes
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4674
> URL: https://issues.jboss.org/browse/ISPN-4674
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 7.0.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Upon a topology change, the client receives:
> {code}
> 17:27:57,406 WARNING [com.example.Main] (main) Loop 43058 failed.: java.lang.ArrayIndexOutOfBoundsException: 2
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyAndHash(Codec20.java:334) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyIfPresent(Codec20.java:310) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:78) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:71) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:49) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at com.example.Main.main(Main.java:31) [:]
> 17:28:02,410 ERROR [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004003: Invalid magic number. Expected 0xa1 and received 0x0
> 17:28:02,412 WARNING [com.example.Main] (main) Loop 43059 failed.: org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x0
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:247) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:68) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:49) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at com.example.Main.main(Main.java:31) [:]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4599:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1, https://bugzilla.redhat.com/show_bug.cgi?id=1134476 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4599:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (ISPN-4602) Verify EntryIterator works with MarshalledValues
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4602?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4602:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1128811|https://bugzilla.redhat.com/show_bug.cgi?id=1128811] from VERIFIED to ON_QA
> Verify EntryIterator works with MarshalledValues
> ------------------------------------------------
>
> Key: ISPN-4602
> URL: https://issues.jboss.org/browse/ISPN-4602
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Marshalling
> Affects Versions: 7.0.0.Alpha5
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Beta1
>
>
> The EntryIterator currently doesn't deserialize MarshalledValues as needed which would cause filter failures and the incorrect values to be returned.
> This also means each key/value pair would need to be deserialized when applied to filter which will be slower and should be noted in documentation, but sent across as MarshalledValues?. The only other way is to use some sort of proxy for each object to force lazy deserialization on referencing a field when applying filter, but this seems overkill.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (ISPN-4602) Verify EntryIterator works with MarshalledValues
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4602?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4602:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1128811|https://bugzilla.redhat.com/show_bug.cgi?id=1128811] from ON_QA to VERIFIED
> Verify EntryIterator works with MarshalledValues
> ------------------------------------------------
>
> Key: ISPN-4602
> URL: https://issues.jboss.org/browse/ISPN-4602
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Marshalling
> Affects Versions: 7.0.0.Alpha5
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Beta1
>
>
> The EntryIterator currently doesn't deserialize MarshalledValues as needed which would cause filter failures and the incorrect values to be returned.
> This also means each key/value pair would need to be deserialized when applied to filter which will be slower and should be noted in documentation, but sent across as MarshalledValues?. The only other way is to use some sort of proxy for each object to force lazy deserialization on referencing a field when applying filter, but this seems overkill.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (ISPN-4485) Remote non-indexed query fails if compat mode enabled
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4485?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4485:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1120249|https://bugzilla.redhat.com/show_bug.cgi?id=1120249] from ON_QA to VERIFIED
> Remote non-indexed query fails if compat mode enabled
> -----------------------------------------------------
>
> Key: ISPN-4485
> URL: https://issues.jboss.org/browse/ISPN-4485
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Querying
> Affects Versions: 7.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 630
> Fix For: 7.0.0.Beta1
>
>
> NonIndexedEmbeddedCompatTest.testRemoteQuery fails:
> {quote}
> 2014-07-07 12:33:40,333 ERROR [HotRodDecoder] (HotRodServerWorker-12-1) ISPN005003: Exception reported
> java.lang.IllegalStateException: Unknown entity name sample_bank_account.Account
> at org.infinispan.objectfilter.impl.hql.FilterQueryResolverDelegate.registerPersisterSpace(FilterQueryResolverDelegate.java:47)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.entityName(GeneratedHQLResolver.java:12729)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpaceRoot(GeneratedHQLResolver.java:3064)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpace(GeneratedHQLResolver.java:2956)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpaces(GeneratedHQLResolver.java:2893)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.fromClause(GeneratedHQLResolver.java:2803)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.selectFrom(GeneratedHQLResolver.java:2704)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.querySpec(GeneratedHQLResolver.java:2182)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryExpression(GeneratedHQLResolver.java:2106)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatement(GeneratedHQLResolver.java:1745)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatementSet(GeneratedHQLResolver.java:1658)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.statement(GeneratedHQLResolver.java:654)
> at org.hibernate.hql.ast.spi.QueryResolverProcessor.process(QueryResolverProcessor.java:52)
> at org.hibernate.hql.QueryParser.parseQuery(QueryParser.java:82)
> at org.infinispan.objectfilter.impl.BaseMatcher.parse(BaseMatcher.java:200)
> at org.infinispan.objectfilter.impl.BaseMatcher.getObjectFilter(BaseMatcher.java:91)
> at org.infinispan.objectfilter.impl.ReflectionMatcher.getObjectFilter(ReflectionMatcher.java:19)
> at org.infinispan.query.dsl.embedded.impl.FilterAndConverter.getObjectFilter(FilterAndConverter.java:68)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedQuery.<init>(EmbeddedQuery.java:51)
> at org.infinispan.query.remote.QueryFacadeImpl.executeNonIndexedQuery(QueryFacadeImpl.java:83)
> at org.infinispan.query.remote.QueryFacadeImpl.query(QueryFacadeImpl.java:70)
> at org.infinispan.server.hotrod.Decoder2x$.customReadKey(Decoder2x.scala:297)
> at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:155)
> at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeKey(AbstractProtocolDecoder.scala:170)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:71)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:61)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149)
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> at java.lang.Thread.run(Thread.java:745)
> 2014-07-07 12:33:40,335 ERROR [HotRodDecoder] (HotRodServerWorker-12-1) ISPN005009: Unexpected error before any request parameters read
> io.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: Unknown entity name sample_bank_account.Account
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:417)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149)
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: Unknown entity name sample_bank_account.Account
> at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:204)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:77)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:61)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362)
> ... 12 more
> Caused by: java.lang.IllegalStateException: Unknown entity name sample_bank_account.Account
> at org.infinispan.objectfilter.impl.hql.FilterQueryResolverDelegate.registerPersisterSpace(FilterQueryResolverDelegate.java:47)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.entityName(GeneratedHQLResolver.java:12729)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpaceRoot(GeneratedHQLResolver.java:3064)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpace(GeneratedHQLResolver.java:2956)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpaces(GeneratedHQLResolver.java:2893)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.fromClause(GeneratedHQLResolver.java:2803)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.selectFrom(GeneratedHQLResolver.java:2704)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.querySpec(GeneratedHQLResolver.java:2182)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryExpression(GeneratedHQLResolver.java:2106)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatement(GeneratedHQLResolver.java:1745)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatementSet(GeneratedHQLResolver.java:1658)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.statement(GeneratedHQLResolver.java:654)
> at org.hibernate.hql.ast.spi.QueryResolverProcessor.process(QueryResolverProcessor.java:52)
> at org.hibernate.hql.QueryParser.parseQuery(QueryParser.java:82)
> at org.infinispan.objectfilter.impl.BaseMatcher.parse(BaseMatcher.java:200)
> at org.infinispan.objectfilter.impl.BaseMatcher.getObjectFilter(BaseMatcher.java:91)
> at org.infinispan.objectfilter.impl.ReflectionMatcher.getObjectFilter(ReflectionMatcher.java:19)
> at org.infinispan.query.dsl.embedded.impl.FilterAndConverter.getObjectFilter(FilterAndConverter.java:68)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedQuery.<init>(EmbeddedQuery.java:51)
> at org.infinispan.query.remote.QueryFacadeImpl.executeNonIndexedQuery(QueryFacadeImpl.java:83)
> at org.infinispan.query.remote.QueryFacadeImpl.query(QueryFacadeImpl.java:70)
> at org.infinispan.server.hotrod.Decoder2x$.customReadKey(Decoder2x.scala:297)
> at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:155)
> at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeKey(AbstractProtocolDecoder.scala:170)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:71)
> ... 14 more
> 2014-07-07 12:33:40,338 WARN [Codec20] (main) ISPN004005: Error received from the server: io.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: Unknown entity name sample_bank_account.Account
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[18] returned server error (status=0x85): io.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: Unknown entity name sample_bank_account.Account
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:285)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:85)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:71)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:57)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:24)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:49)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.executeQuery(RemoteQuery.java:72)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.list(RemoteQuery.java:62)
> at org.infinispan.client.hotrod.marshall.EmbeddedCompatTest.testRemoteQuery(EmbeddedCompatTest.java:137)
> at org.infinispan.client.hotrod.marshall.NonIndexedEmbeddedCompatTest.testRemoteQuery(NonIndexedEmbeddedCompatTest.java:34)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (ISPN-4099) Local Listeners can raise entry events on rehash
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4099?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-4099:
-------------------------------------
Actuallly with ISPN-4105, this could be an issue for clustered REPL caches as well, since it no longer relies on primaryOnly.
> Local Listeners can raise entry events on rehash
> ------------------------------------------------
>
> Key: ISPN-4099
> URL: https://issues.jboss.org/browse/ISPN-4099
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Listeners
> Affects Versions: 7.0.0.Alpha1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Final
>
>
> -Cluster Listeners currently raise all create, modify and remove events. When a rehash event occurs this would cause a create event to be generated even though it wasn't just added to the cache. We need to not raise an event in this case.-
> Writing up tests for this, cluster listeners are unaffected as they use the primaryOnly value for the listener. Further testing shows that this only affects local listeners when they become a backup owner from not being an owner.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (ISPN-4491) Cluster Listener Event Batching
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4491?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-4491:
-------------------------------------
Thinking about this more, this can only be true with no converter or the same converter per filter combination.
> Cluster Listener Event Batching
> -------------------------------
>
> Key: ISPN-4491
> URL: https://issues.jboss.org/browse/ISPN-4491
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Listeners
> Affects Versions: 7.0.0.Alpha4
> Reporter: William Burns
> Assignee: William Burns
>
> Currently when a local listener which was installed for a cluster listener finds an event to send back to the parent it does this 1 message per listener. It might be more beneficial if we had batching so that it wouldn't send 1 message per.
> There are 2 cases I can think of which this would benefit.
> # When the underlying transport is UDP. In this case we can send just 1 message to all the nodes for the event instead of N Unicasts
> # When a node has more than 1 cluster listener installed we could send a single message to notifiy more than 1 listener.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (ISPN-4652) Passivation with shared CacheLoader is not working properly
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4652?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4652:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Passivation with shared CacheLoader is not working properly
> -----------------------------------------------------------
>
> Key: ISPN-4652
> URL: https://issues.jboss.org/browse/ISPN-4652
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 7.0.0.Beta1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Beta2
>
>
> The activation does not interact with the shared cache store. This creates a problem for the RemoveCommand (at least) since the value is never removed (similar to https://issues.jboss.org/browse/ISPN-4649)
> Unfortunately, this will need a little more thinking how to solve it since only the primary owner should activate (i.e. remove it) from the shared store.
> Tests in LocalConditionalCommandTest and ClusteredConditionalCommandTest are disabled to because they are hitting this issue.
> (ps to myself: don't forget to re-enabled them)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months