[JBoss JIRA] (ISPN-8445) Off-heap container doesn't work in compatibility mode
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8445?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-8445 at 10/27/17 8:32 AM:
-------------------------------------------------------------------
Thanks [~vjuranek].
Before starting to throw and error though, I need to check if it's possible to interop between Rest and Hot Rod under OFF_HEAP without compat mode, using different marshallers in the HR client. I know that it works for the UTF8String marshaller, need to check for others.
was (Author: gustavonalle):
Thanks [~vjuranek].
Before starting to throw and error though, I need to check if it's possible to interop between Rest and Hot Rod under OFF_HEAP without compat mode, using different marshaller in the HR client. I know that it works for the UTF8String marshaller, need to check for others.
> Off-heap container doesn't work in compatibility mode
> -----------------------------------------------------
>
> Key: ISPN-8445
> URL: https://issues.jboss.org/browse/ISPN-8445
> Project: Infinispan
> Issue Type: Bug
> Components: Off Heap
> Affects Versions: 9.2.0.Alpha1
> Reporter: Vojtech Juranek
>
> When cache uses off-heap container and has compatibility mode turned on, it's not able to convert keys/value into proper type and fails with (when accessed via hotrod or rest)
> {noformat}
> ESC[0mESC[31m14:27:46,383 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (HotRod-ServerHandler-6-1) ISPN000136: Error executing command PutKeyValueCommand, writing keys [key1]: java.lang.ClassCastException: java.la
> ng.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes
> at org.infinispan.container.offheap.OffHeapDataContainer.put(OffHeapDataContainer.java:39)
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:134)
> at org.infinispan.statetransfer.CommitManager.commitEntry(CommitManager.java:141)
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:101)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(ClusteringDependentLogic.java:329)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:183)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:585)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:808)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:562)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.applyChanges(EntryWrappingInterceptor.java:618)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.lambda$setSkipRemoteGetsAndInvokeNextForDataCommand$7(EntryWrappingInterceptor.java:674)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:109)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:671)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:316)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:154)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:135)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:38)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:85)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:154)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:200)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:162)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitPutKeyValueCommand(DDAsyncInterceptor.java:60)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:127)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:96)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1674)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1322)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1788)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:318)
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:439)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:318)
> at org.infinispan.server.hotrod.CacheDecodeContext.put(CacheDecodeContext.java:404)
> at org.infinispan.server.hotrod.ContextHandler.realRead(ContextHandler.java:65)
> at org.infinispan.server.hotrod.ContextHandler.lambda$channelRead0$0(ContextHandler.java:52)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (ISPN-8445) Off-heap container doesn't work in compatibility mode
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-8445?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-8445:
---------------------------------------
as [discussed|https://github.com/infinispan/infinispan/pull/5544#discussion_r...] under [PR #5544|https://github.com/infinispan/infinispan/pull/5544], off-heap and compatibility are incompatible, but ISPN should throw an exception when such config occurs and this should be documented, so keeping this issue open.
> Off-heap container doesn't work in compatibility mode
> -----------------------------------------------------
>
> Key: ISPN-8445
> URL: https://issues.jboss.org/browse/ISPN-8445
> Project: Infinispan
> Issue Type: Bug
> Components: Off Heap
> Affects Versions: 9.2.0.Alpha1
> Reporter: Vojtech Juranek
>
> When cache uses off-heap container and has compatibility mode turned on, it's not able to convert keys/value into proper type and fails with (when accessed via hotrod or rest)
> {noformat}
> ESC[0mESC[31m14:27:46,383 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (HotRod-ServerHandler-6-1) ISPN000136: Error executing command PutKeyValueCommand, writing keys [key1]: java.lang.ClassCastException: java.la
> ng.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes
> at org.infinispan.container.offheap.OffHeapDataContainer.put(OffHeapDataContainer.java:39)
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:134)
> at org.infinispan.statetransfer.CommitManager.commitEntry(CommitManager.java:141)
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:101)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(ClusteringDependentLogic.java:329)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:183)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:585)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:808)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:562)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.applyChanges(EntryWrappingInterceptor.java:618)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.lambda$setSkipRemoteGetsAndInvokeNextForDataCommand$7(EntryWrappingInterceptor.java:674)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:109)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:671)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:316)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:154)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:135)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:38)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:85)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:154)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:200)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:162)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitPutKeyValueCommand(DDAsyncInterceptor.java:60)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:127)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:96)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1674)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1322)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1788)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:318)
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:439)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:318)
> at org.infinispan.server.hotrod.CacheDecodeContext.put(CacheDecodeContext.java:404)
> at org.infinispan.server.hotrod.ContextHandler.realRead(ContextHandler.java:65)
> at org.infinispan.server.hotrod.ContextHandler.lambda$channelRead0$0(ContextHandler.java:52)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (ISPN-8257) BackupForStateTransferTest.testStateTransferWithClusterIdle random failures
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8257?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-8257:
-----------------------------------
Probably related failure in org.infinispan.xsite.statetransfer.DistSyncOnePhaseWriteSkewTxStateTransferTest.testStateTransferWithClusterIdle[null, tx=false]:
{code}
java.lang.AssertionError:
at org.infinispan.xsite.statetransfer.BaseStateTransferTest$20.assertInCache(BaseStateTransferTest.java:601)
at org.infinispan.xsite.AbstractXSiteTest.assertInSite(AbstractXSiteTest.java:172)
at org.infinispan.xsite.statetransfer.BaseStateTransferTest.assertNoStateTransferInReceivingSite(BaseStateTransferTest.java:596)
at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testStateTransferWithClusterIdle(BaseStateTransferTest.java:199)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
http://ci.infinispan.org/job/Infinispan/job/PR-5539/1/testReport/junit/or...
> BackupForStateTransferTest.testStateTransferWithClusterIdle random failures
> ---------------------------------------------------------------------------
>
> Key: ISPN-8257
> URL: https://issues.jboss.org/browse/ISPN-8257
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.1.0.Final
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 9.1.1.Final
>
>
> http://ci.infinispan.org/job/Infinispan/job/master/118/testReport/junit/o...
> {code}
> java.lang.AssertionError:
> at org.infinispan.xsite.statetransfer.BackupForStateTransferTest$6.assertInCache(BackupForStateTransferTest.java:138)
> at org.infinispan.xsite.AbstractXSiteTest.assertInSite(AbstractXSiteTest.java:178)
> at org.infinispan.xsite.statetransfer.BackupForStateTransferTest.assertNoStateTransferInReceivingSite(BackupForStateTransferTest.java:133)
> at org.infinispan.xsite.statetransfer.BackupForStateTransferTest.testStateTransferWithClusterIdle(BackupForStateTransferTest.java:94)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 20 stack frames
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (ISPN-8411) Add support for efficient removeAll
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8411?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8411:
------------------------------
Status: Open (was: New)
> Add support for efficient removeAll
> -----------------------------------
>
> Key: ISPN-8411
> URL: https://issues.jboss.org/browse/ISPN-8411
> Project: Infinispan
> Issue Type: Feature Request
> Components: Hibernate Cache
> Affects Versions: 8.2.8.Final, 9.1.1.Final
> Environment: WildFly 10.1.0, WildFly 11.0.0.CR1, WildFly master, Hibernate 2LC
> Reporter: Emond Papegaaij
> Assignee: Galder Zamarreño
>
> Infinispan currently does not seem to implement an efficient way to clear an entire cache cluster-wide. This forces Hibernate to remove all entries one by one when a cache region needs to be cleared, for example when a buld CriteriaUpdate or CriteriaDelete is used.
> The behavior we are observing is:
> # All nodes in the cluster are queried for the keyset in a region
> # A lock seems to be in place for this region for the duration of the commit
> # The initiating node constructs a message with {{InvalidateCommands}} for all keys
> # This large message (230MB for 200k entries) is sent to all nodes in the cluster
> For large caches this can take very long. We had to increase the remote-timeout to 60 seconds to prevent timeouts. During this time, the entire cluster is locked an busy processing the cache invalidations. As you can understand, this is not a workable solution for us. On some places we can prevent the cache clear by updating the records one by one, but in other places this is not an option.
> The corresponding report at Hibernate can be found here: https://hibernate.atlassian.net/browse/HHH-12036
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (ISPN-8411) Add support for efficient removeAll
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8411?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8411:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5539
> Add support for efficient removeAll
> -----------------------------------
>
> Key: ISPN-8411
> URL: https://issues.jboss.org/browse/ISPN-8411
> Project: Infinispan
> Issue Type: Feature Request
> Components: Hibernate Cache
> Affects Versions: 8.2.8.Final, 9.1.1.Final
> Environment: WildFly 10.1.0, WildFly 11.0.0.CR1, WildFly master, Hibernate 2LC
> Reporter: Emond Papegaaij
> Assignee: Galder Zamarreño
>
> Infinispan currently does not seem to implement an efficient way to clear an entire cache cluster-wide. This forces Hibernate to remove all entries one by one when a cache region needs to be cleared, for example when a buld CriteriaUpdate or CriteriaDelete is used.
> The behavior we are observing is:
> # All nodes in the cluster are queried for the keyset in a region
> # A lock seems to be in place for this region for the duration of the commit
> # The initiating node constructs a message with {{InvalidateCommands}} for all keys
> # This large message (230MB for 200k entries) is sent to all nodes in the cluster
> For large caches this can take very long. We had to increase the remote-timeout to 60 seconds to prevent timeouts. During this time, the entire cluster is locked an busy processing the cache invalidations. As you can understand, this is not a workable solution for us. On some places we can prevent the cache clear by updating the records one by one, but in other places this is not an option.
> The corresponding report at Hibernate can be found here: https://hibernate.atlassian.net/browse/HHH-12036
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (ISPN-8356) Embedded distribution names are confusing
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8356?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8356:
--------------------------------
Fix Version/s: 9.2.0.Beta1
(was: 9.2.0.Alpha2)
> Embedded distribution names are confusing
> -----------------------------------------
>
> Key: ISPN-8356
> URL: https://issues.jboss.org/browse/ISPN-8356
> Project: Infinispan
> Issue Type: Enhancement
> Components: Build process
> Affects Versions: 9.1.1.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.2.0.Beta1
>
>
> The binary distribution names for embedded libraries are confusing:
> I propose the following names
>
> - infinispan-${version}-all.zip -> infinispan-embedded-${version}-all.zip
> - infinispan-${version}-minimal.zip -> infinispan-embedded-${version}-minimal.zip
> - infinispan-${version}-remote.zip -> infinispan-remote-${version}.zip
> The website labelling needs to be modified accordingly too
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (ISPN-8344) DSL queries filtering only on type are always executed without index
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8344?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8344:
--------------------------------
Fix Version/s: 9.2.0.Beta1
(was: 9.2.0.Alpha2)
> DSL queries filtering only on type are always executed without index
> --------------------------------------------------------------------
>
> Key: ISPN-8344
> URL: https://issues.jboss.org/browse/ISPN-8344
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 9.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 9.0.4.Final, 8.2.9.Final, 9.1.2.Final, 9.2.0.Beta1
>
>
> This happens if the WHERE clause is empty or a tautology (true). In this case the query is wrongly executed unindexed even though the index should be at least used for filtering on type.
> The query
> {code}
> FROM org.infinispan.test.Person
> {code}
> or
> {code}
> qf.from(Person.class).build();
> {code}
> is such a case
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months