October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4852) PartitionHandling: support replicated caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4852?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4852: ------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/infinispan/infinispan/pull/2968 (was: https://github.com/infinispan/infinispan/pull/2964) > PartitionHandling: support replicated caches > -------------------------------------------- > > Key: ISPN-4852 > URL: https://issues.jboss.org/browse/ISPN-4852 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > ISPN-4574 already did most of the job, but the PartitionHandlingManager component wasn't created for replicated caches. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4776) The topology id for the merged cache topology is not always bigger than all the partition topology ids

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4776?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4776: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/2908, https://github.com/infinispan/infinispan/pull/2964 (was: https://github.com/infinispan/infinispan/pull/2908) > The topology id for the merged cache topology is not always bigger than all the partition topology ids > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-4776 > URL: https://issues.jboss.org/browse/ISPN-4776 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.CR1 > > > With the ISPN-4574 fix, I changed the merge algorithm to pick the partition with the most members (both in the _stable_ topology and in the _current_ topology) instead of the partition with the highest topology id. > However, the biggest topology is not necessarily the partition with the highest topology id, so it's possible that some nodes will ignore the merged topology because they already have a higher topology installed. This happened once in ClusterTopologyManagerTest.testClusterRecoveryAfterThreeWaySplit: > {noformat} > 00:24:59,286 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterCacheStatus] Recovered 3 partition(s) for cache cache: [CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeL-25322: 60+0]}, pendingCH=null, unionCH=null}, CacheTopology{id=6, rebalanceId=3, currentCH=DefaultConsistentHash{ns = 60, owners = (2)[, NodeL-25322: 30+10, NodeN-6727: 30+10]}, pendingCH=DefaultConsistentHash{ns = 60, owners = (2)[, NodeL-25322: 30+30, NodeN-6727: 30+30]}, unionCH=null}, CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}] > 00:24:59,287 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterCacheStatus] Updating topologies after merge for cache cache, current topology = CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}, stable topology = CacheTopology{id=4, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (3)[, NodeL-25322: 20+20, NodeM-12972: 20+20, NodeN-6727: 20+20]}, pendingCH=null, unionCH=null}, availability mode = null > 00:24:59,287 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache cache, topology = CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}, availability mode = null > 00:24:59,288 TRACE (transport-thread-NodeL-p33097-t3:) [LocalTopologyManagerImpl] Ignoring consistent hash update for cache cache, current topology is 8: CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null} > {noformat} > Failure logs here: http://ci.infinispan.org/viewLog.html?buildId=12364&buildTypeId=Infinispa... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4859) Make Soft Index File Store configuration more standard

by Radim Vansa (JIRA)

Radim Vansa created ISPN-4859: --------------------------------- Summary: Make Soft Index File Store configuration more standard Key: ISPN-4859 URL: https://issues.jboss.org/browse/ISPN-4859 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Affects Versions: 7.0.0.CR1 Reporter: Radim Vansa Assignee: Radim Vansa Priority: Minor The configuration uses camel-case etc... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3808) Performance assesment of the Remote Query functionality

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3808?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3808: ----------------------------------- I haven't managed to do any remote querying performance tests yet, therefore, I don't think it's resolved. Maybe 'Rejected' if we don't want to do any tests in community cycle. > Performance assesment of the Remote Query functionality > ------------------------------------------------------- > > Key: ISPN-3808 > URL: https://issues.jboss.org/browse/ISPN-3808 > Project: Infinispan > Issue Type: Task > Components: Remote Querying > Reporter: Sanne Grinovero > Assignee: Radim Vansa > Labels: 6.3remotequeries, 64QueryBlockers > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4853) OSGI metadata import-package version ranges are too narrow

by Andrew Scully (JIRA)

[ https://issues.jboss.org/browse/ISPN-4853?page=com.atlassian.jira.plugin.... ] Andrew Scully commented on ISPN-4853: ------------------------------------- Yes you are right, the blueprint implementation should export that package. Unfortunately, popularly used versions of the two big Blueprint frameworks historically did not: https://bugs.eclipse.org/bugs/show_bug.cgi?id=351755 https://issues.apache.org/jira/browse/ARIES-670 I think you are correct to import the package, however, the burden should be on the Blueprint container to provide the package rather than on you / me to work around it. I only raised it because projects sometimes do not, for that reason, hence why I was "dubious". > OSGI metadata import-package version ranges are too narrow > ---------------------------------------------------------- > > Key: ISPN-4853 > URL: https://issues.jboss.org/browse/ISPN-4853 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.CR1 > Environment: Any OSGI environment (but found on Glassfish / Apache Felix). > Reporter: Andrew Scully > Labels: OSGI, bundle, import, package > > The OSGI import-package statement is specifying specific dependencies on a number of packages, rather than a range. This makes it impossible to install Infinispan 7 in any OSGI environment that doesn't have the exact versions of the dependencies present. > Normally, the version range for dependencies would range from the major:minor:revision of the minimum requirement, up to the next major version (exclusive). > I've copied and pasted the "Imported Packages" output below from my Apache Felix bundle console for the infinispan-core bundle. > The bundle will not resolve because the versions of javax.transaction, JGroups, jboss-marshalling and jboss-logging are slightly newer than those required. > The org.osgi.service.blueprint dependency is also dubious -- I'm not sure you usually have a runtime dependency on this package (even if you use Blueprint). > For example, the following statement... > org.jboss.marshalling;version="[1.4.4.Final,1.4.4.Final]" > ...should probably be... > org.jboss.marshalling;version="[1.4.4.Final,2)" > ...in order to comply with standard semantic versioning policy. > Felix output: > javax.management from org.apache.felix.framework (0) > javax.naming from org.apache.felix.framework (0) > javax.security.auth from org.apache.felix.framework (0) > javax.transaction,version=[1.1.0,1.1.0] -- Cannot be resolved > javax.transaction.xa,version=[1.1.0,1.1.0] -- Cannot be resolved > javax.xml.namespace from org.apache.felix.framework (0) > javax.xml.parsers from org.apache.felix.framework (0) > javax.xml.stream from org.apache.felix.framework (0) > javax.xml.transform from org.apache.felix.framework (0) > javax.xml.transform.dom from org.apache.felix.framework (0) > javax.xml.transform.stream from org.apache.felix.framework (0) > net.jcip.annotations from com.springsource.net.jcip.annotations (62) > org.infinispan.commons,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.api,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.configuration,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.equivalence,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.executors,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.hash,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.io,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.logging,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.marshall,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.marshall.jboss,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.util,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.util.concurrent,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.util.concurrent.jdk8backported,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.jboss.logging,version=[3.1.2.GA,3.1.2.GA] -- Cannot be resolved > org.jboss.marshalling,version=[1.4.4.Final,1.4.4.Final] -- Cannot be resolved > org.jboss.marshalling.util,version=[1.4.4.Final,1.4.4.Final] -- Cannot be resolved > org.jgroups,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.blocks,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.blocks.mux,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.jmx,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.logging,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.protocols,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.protocols.relay,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.protocols.tom,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.stack,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.util,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.osgi.service.blueprint,version=[1.0.0,2.0.0) -- Cannot be resolved > org.w3c.dom from org.apache.felix.framework (0) > org.xml.sax from org.apache.felix.framework (0) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4858) SoftIndexFileStoreTest.testStoreAndRemove random failures

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4858?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4858: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2967 > SoftIndexFileStoreTest.testStoreAndRemove random failures > --------------------------------------------------------- > > Key: ISPN-4858 > URL: https://issues.jboss.org/browse/ISPN-4858 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Radim Vansa > > CI: http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=554... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4858) SoftIndexFileStoreTest.testStoreAndRemove random failures

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4858?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4858: ------------------------------ Status: Open (was: New) > SoftIndexFileStoreTest.testStoreAndRemove random failures > --------------------------------------------------------- > > Key: ISPN-4858 > URL: https://issues.jboss.org/browse/ISPN-4858 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Radim Vansa > > CI: http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=554... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4858) SoftIndexFileStoreTest.testStoreAndRemove random failures

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4858?page=com.atlassian.jira.plugin.... ] Radim Vansa reassigned ISPN-4858: --------------------------------- Assignee: Radim Vansa > SoftIndexFileStoreTest.testStoreAndRemove random failures > --------------------------------------------------------- > > Key: ISPN-4858 > URL: https://issues.jboss.org/browse/ISPN-4858 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Radim Vansa > > CI: http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=554... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4858) SoftIndexFileStoreTest.testStoreAndRemove random failures

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-4858: --------------------------------------- Summary: SoftIndexFileStoreTest.testStoreAndRemove random failures Key: ISPN-4858 URL: https://issues.jboss.org/browse/ISPN-4858 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 7.0.0.CR1 Reporter: Gustavo Fernandes CI: http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=554... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4847) Improve indexing performance

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4847?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4847: ------------------------------ Description: This JIRA is focused on optimizing performance of use case where the application uses short or none transactions - therefore, no batching can be applied - and then performs the query and expects that the result will be consistent (please, specify in documentation if any lag after cache.put() or tx.commit() is required and if the application can detect that the update has been applied). We are well aware (see BZ) that indexing can be implemented with very low overhead, but the throughput is thousands of times lower [1] (configuration in [2]) with distributed mode storing index in replicated cache, and about 4x slowdown when comparing replicated cache without indexing and indexing to NRT FS/RAM. [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-query-index... [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-query-index... was: This JIRA is focused on optimizing performance of use case where the application uses short or none transactions - therefore, no batching can be applied - and then performs the query and expects that the result will be consistent (please, specify in documentation if any lag after cache.put() or tx.commit() is required and if the application can detect that the update has been applied). Performance of indexing is currently insufficient, when compared to competitors. Competitors show very low overhead of indexed writes, while we can see that the throughput is thousands of times lower [1] (configuration in [2]) with distributed mode storing index in replicated cache, and about 4x slowdown when comparing replicated cache without indexing and indexing to NRT FS/RAM. [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-query-index... [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-query-index... > Improve indexing performance > ---------------------------- > > Key: ISPN-4847 > URL: https://issues.jboss.org/browse/ISPN-4847 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Lucene Directory > Affects Versions: 7.0.0.CR1 > Reporter: Radim Vansa > Assignee: Sanne Grinovero > Priority: Critical > > This JIRA is focused on optimizing performance of use case where the application uses short or none transactions - therefore, no batching can be applied - and then performs the query and expects that the result will be consistent (please, specify in documentation if any lag after cache.put() or tx.commit() is required and if the application can detect that the update has been applied). > We are well aware (see BZ) that indexing can be implemented with very low overhead, but the throughput is thousands of times lower [1] (configuration in [2]) with distributed mode storing index in replicated cache, and about 4x slowdown when comparing replicated cache without indexing and indexing to NRT FS/RAM. > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-query-index... > [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-query-index... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2014