[JBoss JIRA] (ISPN-5988) Fine-/Coarse-grained AtomicMap info is not preserved in cache
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5988?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5988:
------------------------------
Status: Open (was: New)
> Fine-/Coarse-grained AtomicMap info is not preserved in cache
> -------------------------------------------------------------
>
> Key: ISPN-5988
> URL: https://issues.jboss.org/browse/ISPN-5988
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.0.Beta1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
>
> In `AtomicMapAPITest#testAtomicMapAfterFineGrainedAtomicMap` we test that one entry cannot be mapped to both fine- and coarse-grained atomic map. However, the test relies on local node being owner, because the check is based on type of the proxy - but the proxy is not persisted in cache.
> So in practice you can access the fine-grained map as coarse-grained and vice versa.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-6022) Unable to query cache when data is preloaded via AdvancedCacheLoader#process
by Dan Siviter (JIRA)
[ https://issues.jboss.org/browse/ISPN-6022?page=com.atlassian.jira.plugin.... ]
Dan Siviter updated ISPN-6022:
------------------------------
Description:
When preloading from a {{AdvancedCacheLoader}} the index doesn't get updated. Therefore it is only possible to query items that have been {{#put(...)}} into the cache. I am able to get preloaded items from the cache using their key which leads me to think the index is never built on pre-load.
I've seen no implicit rebuilding of caches in any of the existing {{AdvancedCacheLoader#process(...)}} which leads me to think this will not work with any of them.
I've verified this reindexing using {{searchManager.getMassIndexer().start()}} and the query will then return results.
was:
When preloading from a {{AdvancedCacheLoader}} the index doesn't get updated. Therefore it is only possible to query items that have been put into the cache. I am able to get preloaded items from the cache using their key which leads me to think the index is never built on pre-load.
I've seen no implicit rebuilding of caches in any of the existing {{AdvancedCacheLoader#process(...)}} which leads me to think this will not work with any of them.
I've verified this reindexing using {{searchManager.getMassIndexer().start()}} and the query will then return results.
> Unable to query cache when data is preloaded via AdvancedCacheLoader#process
> ----------------------------------------------------------------------------
>
> Key: ISPN-6022
> URL: https://issues.jboss.org/browse/ISPN-6022
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Loaders and Stores
> Affects Versions: 8.1.0.Final
> Reporter: Dan Siviter
>
> When preloading from a {{AdvancedCacheLoader}} the index doesn't get updated. Therefore it is only possible to query items that have been {{#put(...)}} into the cache. I am able to get preloaded items from the cache using their key which leads me to think the index is never built on pre-load.
> I've seen no implicit rebuilding of caches in any of the existing {{AdvancedCacheLoader#process(...)}} which leads me to think this will not work with any of them.
> I've verified this reindexing using {{searchManager.getMassIndexer().start()}} and the query will then return results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-5981) Compatibility mode: HotRod client sends request to wrong owner
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5981?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5981:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3893
> Compatibility mode: HotRod client sends request to wrong owner
> --------------------------------------------------------------
>
> Key: ISPN-5981
> URL: https://issues.jboss.org/browse/ISPN-5981
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.0.1.Final, 8.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Attachments: GetAllCompatDistTest.java
>
>
> The HotRod client computes the hash on the serialized key, i.e. {{MurmurHash3.hash(obj2bytes(key))}}, but the server decides the entry location based on the unmarshalled key, i.e. {{MurmurHash3.hash(key.hashCode())}}.
> I've modified {{GetAllCompatDistTest}} (attached) to test if there are any {{ClusteredGetCommand}}s being sent for {{RemoteCache.get(key)}} operations, and it finds quite a few:
> {noformat}
> java.lang.AssertionError: expected:<100> but was:<147>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.8.8.jar:?]
> at org.infinispan.client.hotrod.GetAllCompatDistTest.testGetWithCompatibility(GetAllCompatDistTest.java:57) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-5493) SiteProviderTopologyChangeTest.testXSiteSTDuringLeave random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5493?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5493:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3892
> SiteProviderTopologyChangeTest.testXSiteSTDuringLeave random failures
> ---------------------------------------------------------------------
>
> Key: ISPN-5493
> URL: https://issues.jboss.org/browse/ISPN-5493
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Cross-Site Replication, Test Suite - Core
> Affects Versions: 7.2.1.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Blocker
> Labels: testsuite_failure
> Fix For: 8.2.0.Alpha1
>
> Attachments: SiteProviderTopologyChangeTest.log.gz
>
>
> Looks like the node is killed before the {{XSiteStateTransferControlCommand(START_SEND)}} command was replicated to all the nodes in the source cluster, and the {{SuspectException}} stops the state push:
> {noformat}
> 23:33:22,834 DEBUG (testng-SiteProviderTopologyChangeTest:) [XSiteAdminOperations] Unable to pushState to 'NYC'.java.lang.Exception: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: SiteProviderTopologyChangeTest-NodeBG-25313
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.startPushState(XSiteStateTransferManagerImpl.java:151)
> at org.infinispan.xsite.XSiteAdminOperations.pushState(XSiteAdminOperations.java:238)
> at org.infinispan.xsite.statetransfer.failures.AbstractTopologyChangeTest.startStateTransfer(AbstractTopologyChangeTest.java:144)
> at org.infinispan.xsite.statetransfer.failures.SiteProviderTopologyChangeTest.doXSiteStateTransferDuringTopologyChange(SiteProviderTopologyChangeTest.java:241)
> at org.infinispan.xsite.statetransfer.failures.SiteProviderTopologyChangeTest.testXSiteSTDuringLeave(SiteProviderTopologyChangeTest.java:78)
> Caused by: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: SiteProviderTopologyChangeTest-NodeBG-25313
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.infinispan.commons.util.concurrent.NotifyingFutureImpl.get(NotifyingFutureImpl.java:77)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.invokeRemotelyInLocalSite(XSiteStateTransferManagerImpl.java:376)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.controlStateTransferOnLocalSite(XSiteStateTransferManagerImpl.java:335)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.startPushState(XSiteStateTransferManagerImpl.java:142)
> ... 24 more
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: SiteProviderTopologyChangeTest-NodeBG-25313
> at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:74)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:586)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:287)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:382)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:378)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-5493) SiteProviderTopologyChangeTest.testXSiteSTDuringLeave random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5493?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5493:
------------------------------
Fix Version/s: 8.2.0.Alpha1
> SiteProviderTopologyChangeTest.testXSiteSTDuringLeave random failures
> ---------------------------------------------------------------------
>
> Key: ISPN-5493
> URL: https://issues.jboss.org/browse/ISPN-5493
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Cross-Site Replication, Test Suite - Core
> Affects Versions: 7.2.1.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Blocker
> Labels: testsuite_failure
> Fix For: 8.2.0.Alpha1
>
> Attachments: SiteProviderTopologyChangeTest.log.gz
>
>
> Looks like the node is killed before the {{XSiteStateTransferControlCommand(START_SEND)}} command was replicated to all the nodes in the source cluster, and the {{SuspectException}} stops the state push:
> {noformat}
> 23:33:22,834 DEBUG (testng-SiteProviderTopologyChangeTest:) [XSiteAdminOperations] Unable to pushState to 'NYC'.java.lang.Exception: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: SiteProviderTopologyChangeTest-NodeBG-25313
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.startPushState(XSiteStateTransferManagerImpl.java:151)
> at org.infinispan.xsite.XSiteAdminOperations.pushState(XSiteAdminOperations.java:238)
> at org.infinispan.xsite.statetransfer.failures.AbstractTopologyChangeTest.startStateTransfer(AbstractTopologyChangeTest.java:144)
> at org.infinispan.xsite.statetransfer.failures.SiteProviderTopologyChangeTest.doXSiteStateTransferDuringTopologyChange(SiteProviderTopologyChangeTest.java:241)
> at org.infinispan.xsite.statetransfer.failures.SiteProviderTopologyChangeTest.testXSiteSTDuringLeave(SiteProviderTopologyChangeTest.java:78)
> Caused by: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: SiteProviderTopologyChangeTest-NodeBG-25313
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.infinispan.commons.util.concurrent.NotifyingFutureImpl.get(NotifyingFutureImpl.java:77)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.invokeRemotelyInLocalSite(XSiteStateTransferManagerImpl.java:376)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.controlStateTransferOnLocalSite(XSiteStateTransferManagerImpl.java:335)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferManagerImpl.startPushState(XSiteStateTransferManagerImpl.java:142)
> ... 24 more
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: SiteProviderTopologyChangeTest-NodeBG-25313
> at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:74)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:586)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:287)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:382)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:378)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-5997) JMX operation ClusterCacheStats.resetStatistics() not working
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-5997?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-5997:
-------------------------------------------
[~NadirX] I don't have anything against this approach and we can easily implement this feature/bug by sending DistributedCallable DC to all nodes. DC would, in turn, call reset stats on all cluster nodes using Cache#getStats().reset(). ClusterCacheStats.resetStatistics() would of course continue to reset cluster-wide stats as well. We are slightly mixing apples and oranges here because we use ClusterCacheStats.resetStatistics() to reset not only cluster-wide cache stats but also individual cache stats on all nodes. LMK your thoughts.
> JMX operation ClusterCacheStats.resetStatistics() not working
> -------------------------------------------------------------
>
> Key: ISPN-5997
> URL: https://issues.jboss.org/browse/ISPN-5997
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.1.0.CR1
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
>
> Environment: 2 servers started in domain mode (ISPN 8.1.0.CR1).
> Having some clustered cache, inserted/read some entries (just to create some statistics).
> When connected via JMX (e.g. through JConsole, see https://issues.jboss.org/browse/ISPN-5983 ) to one of the servers, I execute resetStatistics() operation on ClusterCacheStats MBean (object name: jboss.datagrid-infinispan:type=Cache,name="<cache-name>",manager="<cache-container-name>",component=ClusterCacheStats) and nothing happens, the cluster statistics are not reset.
> To actually reset the statistics, I have to connect to each of the servers in domain individually and call resetStatistics() on Statistics MBean, which deletes "a portion" of statistics of that particular server to the cluster stats.
> I would expect ClusterCacheStats.resetStatistics() to do exactly the same: call Statistics.resetStatistics() on each server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months