November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4033) ConcurrentInterceptorVisibilityTest.testGetVisibility random failures

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4033?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4033: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > ConcurrentInterceptorVisibilityTest.testGetVisibility random failures > --------------------------------------------------------------------- > > Key: ISPN-4033 > URL: https://issues.jboss.org/browse/ISPN-4033 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Labels: testsuite_stability > Fix For: 7.1.0.Beta1 > > Attachments: ConcurrentInterceptorVisibilityTest.log > > > http://ci.infinispan.org/viewLog.html?buildId=5934&tab=buildResultsDiv&bu... > {noformat} > 17:28:43,212 ERROR (testng-ConcurrentInterceptorVisibilityTest:) [UnitTestTestNGListener] Test testGetVisibility(org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest) failed. > java.lang.RuntimeException: java.util.concurrent.TimeoutException > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest$1.call(ConcurrentInterceptorVisibilityTest.java:101) > at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1243) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest.updateCache(ConcurrentInterceptorVisibilityTest.java:52) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest.testGetVisibility(ConcurrentInterceptorVisibilityTest.java:39) > Caused by: java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228) > at java.util.concurrent.FutureTask.get(FutureTask.java:91) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest$1.call(ConcurrentInterceptorVisibilityTest.java:97) > ... 24 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4136) Declarative config for REST rawValues

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4136?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4136: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Declarative config for REST rawValues > ------------------------------------- > > Key: ISPN-4136 > URL: https://issues.jboss.org/browse/ISPN-4136 > Project: Infinispan > Issue Type: Task > Components: Configuration > Reporter: Tristan Tarrant > Fix For: 7.1.0.Beta1 > > > Once ISPN-3514 is in we can add support for the REST rawValues boolean in the new 7.0 parser -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4088) Modify signature of Query/CacheQuery.getResultSize() and related offset/pagination methods to return long

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4088?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4088: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Modify signature of Query/CacheQuery.getResultSize() and related offset/pagination methods to return long > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-4088 > URL: https://issues.jboss.org/browse/ISPN-4088 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > Fix For: 7.1.0.Beta1 > > > The method exists in both new DSL and the classic query api. > It should be clarified whether this method and the related pagination methods should use int or long for specifying offsets within the data, also should decide if the total number of results / results per page is a long or an int - and update all involved method signatures to have a unitary treatment of this issue. > It appears that recent Lucene versions can offer the number of results as long, while older ones offer it as int (should be verified). > This issue was raised in a github conversation here: https://github.com/infinispan/infinispan/pull/2410 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4077) Infinispan REST server welcome page has links to old documetation pages

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4077?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4077: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Infinispan REST server welcome page has links to old documetation pages > ----------------------------------------------------------------------- > > Key: ISPN-4077 > URL: https://issues.jboss.org/browse/ISPN-4077 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.Beta1 > > > Links to old CMS should be switched towards the new infinispan.org. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4075) State transfer should preserve the creation timestamp of entries

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4075?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4075: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > State transfer should preserve the creation timestamp of entries > ---------------------------------------------------------------- > > Key: ISPN-4075 > URL: https://issues.jboss.org/browse/ISPN-4075 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Fix For: 7.1.0.Beta1 > > > State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended. > The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4065) Refuse to store an index on an ASYNC Cache

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4065?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4065: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Refuse to store an index on an ASYNC Cache > ------------------------------------------ > > Key: ISPN-4065 > URL: https://issues.jboss.org/browse/ISPN-4065 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Reporter: Sanne Grinovero > Priority: Minor > Labels: 64QueryBlockers, hackathon > Fix For: 7.1.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4046) New query dsl does not support isNull filters for non-string properties

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4046?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4046: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > New query dsl does not support isNull filters for non-string properties > ----------------------------------------------------------------------- > > Key: ISPN-4046 > URL: https://issues.jboss.org/browse/ISPN-4046 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.1.0.Beta1 > > > String properties can be supported because of Hibernate Search null token, but HSearch only offers this for strings and not for other types. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4182) ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4182?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4182: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4182 > URL: https://issues.jboss.org/browse/ISPN-4182 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.1.0.Beta1 > > > The test should ensure the db url is not the same across nodes of all parallel tests because they all run in the same jvm and the H2 instances might collide. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4176) Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4176?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4176: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction > ---------------------------------------------------------------------------------------------- > > Key: ISPN-4176 > URL: https://issues.jboss.org/browse/ISPN-4176 > Project: Infinispan > Issue Type: Bug > Components: Core, Transactions > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Fix For: 7.1.0.Beta1 > > > {{RecoveryManagerImpl.forceTransactionCompletion()}} modifies the {{GlobalTransaction.address}} of the transaction being committed so that the local node is the originator. But the {{GlobalTransaction.id}} stays the same, we could have two transactions with the same {{GlobalTransaction}} - which shouldn't be possible. > We can't remove the code that changes the {{GlobalTransaction.address}}, because we use it as the originator in other parts of the code. So the only option is to generate a new id as well. > But there is another problem: RecoveryAwareTransactionTable.cleanupStaleTransactions() doesn't release the locks acquired by that transaction on the primary node. So forcing a commit with a different GlobalTransaction will not be able to acquire the locks that were held by the original transaction. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4175) Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4175?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4175: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4175 > URL: https://issues.jboss.org/browse/ISPN-4175 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > Fix For: 7.1.0.Beta1 > > > {code} > 11:47:01,852 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.infinispan.clustered.memcachedCache: org.jboss.msc.service.StartException in service jboss.infinispan.clustered.memcachedCache: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:546) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:517) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:399) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:413) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) > at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > ... 3 more > Caused by: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true > at org.infinispan.factories.AbstractComponentRegistry.throwStackAwareConfigurationException(AbstractComponentRegistry.java:884) > at org.infinispan.factories.AbstractComponentRegistry.getFactory(AbstractComponentRegistry.java:299) > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:270) > at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227) > at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65) > at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797) > at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:148) > at org.infinispan.query.remote.LifecycleManager.initProtobufMetadataManager(LifecycleManager.java:56) > at org.infinispan.query.remote.LifecycleManager.cacheManagerStarted(LifecycleManager.java:70) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228) > ... 12 more > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014