[JBoss JIRA] (ISPN-3229) L1 cache entries should not be passivated
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3229?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3229:
----------------------------
Fix Version/s: 7.0.0.Alpha3
(was: 7.0.0.Alpha2)
> L1 cache entries should not be passivated
> -----------------------------------------
>
> Key: ISPN-3229
> URL: https://issues.jboss.org/browse/ISPN-3229
> Project: Infinispan
> Issue Type: Bug
> Components: L1
> Affects Versions: 5.2.6.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Alpha3
>
> Attachments: DistSyncL1PassivationFuncTest.java
>
>
> L1 entries are stored in the same data container as the real entries. These can be evicted which is fine, however we don't want them to be passivated as this could be costly to write/read from the cache store. We should either prevent L1 cache entries from being passivated or have an option to allow for it.
> Currently L1 entries are not differentiated from other entries except through the fact that they are mortal, which is used for other operations as well, which means they would need a placeholder of some kind to tell the container this is a L1 entry.
--
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
12 years
[JBoss JIRA] (ISPN-3244) TopologyAwareSyncConsistentHashFactory should limit the number of segments per node
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3244?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3244:
----------------------------
Fix Version/s: 7.0.0.Alpha3
(was: 7.0.0.Alpha2)
> TopologyAwareSyncConsistentHashFactory should limit the number of segments per node
> -----------------------------------------------------------------------------------
>
> Key: ISPN-3244
> URL: https://issues.jboss.org/browse/ISPN-3244
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 5.2.6.Final, 5.3.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha3
>
>
> Let's say we have a cluster with 5 nodes: A(r1), B(r2), C(r2), D(r3), E(r3)
> TopologyAwareConsistentSyncHashFactory will spread the segments equally on each rack, meaning A will own 2x segments compared to the other nodes.
> TopologyAwareConsistentHashFactory limits the maximum number per node, so that A owns just as many segments as the other nodes. With a slight limitation: the number of racks must be greater than numOwners, otherwise each rack must hold (at least) one copy of all the data.
> TopologyAwareConsistentSyncHashFactory is a little random, so we can't distribute the data perfectly, but we can limit the number of segments on each node to something like 1.5x the average number of segments.
--
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
12 years
[JBoss JIRA] (ISPN-3448) Tests from org.infinispan.distribution.rehash package fail randomly
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3448?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3448:
----------------------------
Fix Version/s: 7.0.0.Alpha3
(was: 7.0.0.Alpha2)
> Tests from org.infinispan.distribution.rehash package fail randomly
> -------------------------------------------------------------------
>
> Key: ISPN-3448
> URL: https://issues.jboss.org/browse/ISPN-3448
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Alpha3, 6.0.0.CR1, 6.0.0.Final
> Reporter: Jiří Holuša
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 6.0.1.Final, 7.0.0.Alpha3
>
> Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent.log.zip, NonTxStateTransferOverwritingValue2Test.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringPutOverwrite.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemove.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuring{Remove, Replace}WithPreviousValue.log.zip
>
>
> These tests are randomly failing on various platforms (RHEL, Solaris) with various JDKs.
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxJoinerBecomingBackupOwnerTest.testBackupOwnerJoiningDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringJoinStressTest.testNodeJoiningDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxJoinerBecomingBackupOwnerTest.testBackupOwnerJoiningDuringPut
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemove
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringPutOverwrite
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemoveWithPreviousValue
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringReplaceWithPreviousValue
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringReplace
> New randomly failing test
> org.infinispan.distribution.rehash.ConcurrentOverlappingLeaveTest.testNonTransactional
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
12 years
[JBoss JIRA] (ISPN-3402) Add JDBC Cache Store config to RHQ plugin
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3402?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3402:
----------------------------
Fix Version/s: 7.0.0.Alpha3
(was: 7.0.0.Alpha2)
> Add JDBC Cache Store config to RHQ plugin
> -----------------------------------------
>
> Key: ISPN-3402
> URL: https://issues.jboss.org/browse/ISPN-3402
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores, Server
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Alpha3
>
>
> ISPN-3350 was added to enhance some of the RHQ endpoints to allow for better runtime configuration support. However ISPN-3290 is also concurrently changing cache stores. Some changes for ISPN-3290 were mentioned to be possibly changing how the JDBC cache stores are configured and as such this has been excluded from ISPN-3350 to not implement it twice.
> This is just to add in the support JDBC cache stores as they are missing.
--
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
12 years
[JBoss JIRA] (ISPN-3621) Most CacheStore configuration examples in the documentation are wrong (outdated)
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3621?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3621:
----------------------------
Fix Version/s: 7.0.0.Alpha3
(was: 7.0.0.Alpha2)
> Most CacheStore configuration examples in the documentation are wrong (outdated)
> --------------------------------------------------------------------------------
>
> Key: ISPN-3621
> URL: https://issues.jboss.org/browse/ISPN-3621
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation-Core
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha3
>
>
> I've been trying half a dozen configuration snippets from the documentation, I couldn't get any CacheStore to work. All I get from the configuration parser is an unhelpfull stack trace:
> {quote}
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[50,63]
> Message: Unexpected element '{urn:infinispan:config:6.0}loaders' encountered
> at org.infinispan.configuration.parsing.ParseUtils.unexpectedElement(ParseUtils.java:35)
> at org.infinispan.configuration.parsing.Parser60.parseCache(Parser60.java:178)
> at org.infinispan.configuration.parsing.Parser60.parseNamedCache(Parser60.java:109)
> at org.infinispan.configuration.parsing.Parser60.readElement(Parser60.java:76)
> at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:130)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:112)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:99)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:86)
> ... 47 more
> {quote}
> One might think that something (what?) is wrong at [row,col]:[50,63] but I'm copy pasting the documentation.
--
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
12 years
[JBoss JIRA] (ISPN-3530) The HotRod client should support a separate CH for each cache
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3530?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3530:
----------------------------
Fix Version/s: 7.0.0.Alpha3
(was: 7.0.0.Alpha2)
> The HotRod client should support a separate CH for each cache
> -------------------------------------------------------------
>
> Key: ISPN-3530
> URL: https://issues.jboss.org/browse/ISPN-3530
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Affects Versions: 6.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Labels: hotrod, hotrod-java-client
> Fix For: 7.0.0.Alpha3
>
>
> With asymmetric clusters, each cache can have its own consistent hash, so the primary owner of a key in one cache is not necessarily the owner in all the caches. Even with a symmetric cluster, the same client may be used to access both distributed and replicated caches, and those would certainly have a different CH.
> In order to send the operations to the correct owner, the HotRod client should use a different CH for each cache.
--
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
12 years