February 2019 - infinispan-issues

[JBoss JIRA] (ISPN-8196) Activation should occur at the primary node with shared stores

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8196?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8196: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > Activation should occur at the primary node with shared stores > -------------------------------------------------------------- > > Key: ISPN-8196 > URL: https://issues.jboss.org/browse/ISPN-8196 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Final > > > When a cache has passivation enabled and a shared store, any misses on the backup node should result in a call to the primary owner who will then attempt activation from the shared store. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8003) ProtobufMetadataManagerInterceptor fail the InterceptorDefinesAllReadWritesCheck

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8003?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8003: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > ProtobufMetadataManagerInterceptor fail the InterceptorDefinesAllReadWritesCheck > -------------------------------------------------------------------------------- > > Key: ISPN-8003 > URL: https://issues.jboss.org/browse/ISPN-8003 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.0.Final, 9.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 10.0.0.Final > > > {code} > ProtobufMetadataManagerInterceptor.java:43, InterceptorDefinesAllReadWritesCheck, Priority: Normal > Interceptor defines methods [visitPutKeyValueCommand, visitRemoveCommand, visitPutMapCommand, visitReplaceCommand] but does not define [visitReadWriteKeyCommand, visitReadWriteManyCommand, visitReadWriteKeyValueCommand, visitReadWriteManyEntriesCommand] [not required for tests] > {code} > {code} > QueryInterceptor.java:69, InterceptorDefinesAllReadWritesCheck, Priority: Normal > Interceptor defines methods [visitPutKeyValueCommand, visitRemoveCommand, visitPutMapCommand, visitReplaceCommand] but does not define [visitReadWriteKeyCommand, visitReadWriteManyCommand, visitReadWriteKeyValueCommand, visitReadWriteManyEntriesCommand] [not required for tests] > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7982) Ickle purely negative fulltext subqueries cause empty results

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7982?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7982: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > Ickle purely negative fulltext subqueries cause empty results > ------------------------------------------------------------- > > Key: ISPN-7982 > URL: https://issues.jboss.org/browse/ISPN-7982 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.Final > Reporter: Gustavo Fernandes > Assignee: Adrian Nistor > Priority: Major > Fix For: 10.0.0.Final > > > When using parethesis in an Ickle full text predicate, it can generate subqueries that are pure negative, e.g. > {{from IspnEvent where (tags : ('tagA' and (not 'a0')))}} > In Lucene, the query > {{+tags:taga +(-tags:a0)}} > is different from > {{+tags:taga -tags:a0}} > The latter works as expected, but the former brings empty results since Lucene does no support purely negative subqueries. In order for the former query to work, it needs to add all documents as another term to the subquery, for e.g. {{+tags:taga +(\*:\* -tags:a0)}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8622) PessimisticStateTransferLocksTest.testPutStartedDuringRebalance random failure

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8622?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8622: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > PessimisticStateTransferLocksTest.testPutStartedDuringRebalance random failure > ------------------------------------------------------------------------------ > > Key: ISPN-8622 > URL: https://issues.jboss.org/browse/ISPN-8622 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Final > > > {noformat} > java.lang.AssertionError: expected:<[key]> but was:<[]> > at org.infinispan.distribution.rehash.PessimisticStateTransferLocksTest.checkLocksBeforeCommit(PessimisticStateTransferLocksTest.java:185) > at org.infinispan.distribution.rehash.PessimisticStateTransferLocksTest.testPutStartedDuringRebalance(PessimisticStateTransferLocksTest.java:121) > {noformat} > http://ci.infinispan.org/job/Infinispan/job/master/319 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8602) ExpirationSingleFileStoreDistListenerFunctionalTest random failures

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8602?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8602: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > ExpirationSingleFileStoreDistListenerFunctionalTest random failures > ------------------------------------------------------------------- > > Key: ISPN-8602 > URL: https://issues.jboss.org/browse/ISPN-8602 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Beta1 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Final > > > Various {{ExpirationSingleFileStoreDistListenerFunctionalTest}} tests are failing in master: > {noformat} > [ERROR] testExpirationOfStoreWhenDataNotInMemory[null](org.infinispan.expiration.impl.ExpirationSingleFileStoreDistListenerFunctionalTest) Time elapsed: 0.078 s <<< FAILURE! > java.lang.AssertionError: expected:<0> but was:<7> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) > at org.infinispan.expiration.impl.ExpirationStoreListenerFunctionalTest.testExpirationOfStoreWhenDataNotInMemory(ExpirationStoreListenerFunctionalTest.java:55) > {noformat} > {noformat} > [ERROR] testSimpleExpirationLifespan[null](org.infinispan.expiration.impl.ExpirationSingleFileStoreDistListenerFunctionalTest) Time elapsed: 0.045 s <<< FAILURE! > java.lang.AssertionError: expected:<0> but was:<1> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) > at org.infinispan.expiration.impl.ExpirationFunctionalTest.testSimpleExpirationLifespan(ExpirationFunctionalTest.java:78) > at org.infinispan.expiration.impl.ExpirationStoreListenerFunctionalTest.testSimpleExpirationLifespan(ExpirationStoreListenerFunctionalTest.java:37) > {noformat} > {noformat} > [ERROR] testSimpleExpirationMaxIdle[null](org.infinispan.expiration.impl.ExpirationSingleFileStoreDistListenerFunctionalTest) Time elapsed: 0 s <<< FAILURE! > java.lang.AssertionError: expected:<0> but was:<1> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) > at org.infinispan.expiration.impl.ExpirationFunctionalTest.testSimpleExpirationMaxIdle(ExpirationFunctionalTest.java:86) > at org.infinispan.expiration.impl.ExpirationStoreListenerFunctionalTest.testSimpleExpirationMaxIdle(ExpirationStoreListenerFunctionalTest.java:44) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8561) Add maxcontentlength to hot rod server

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8561?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8561: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > Add maxcontentlength to hot rod server > -------------------------------------- > > Key: ISPN-8561 > URL: https://issues.jboss.org/browse/ISPN-8561 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8576) Add authorization to Distributed Locks

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8576?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8576: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > Add authorization to Distributed Locks > -------------------------------------- > > Key: ISPN-8576 > URL: https://issues.jboss.org/browse/ISPN-8576 > Project: Infinispan > Issue Type: Enhancement > Components: Clustered Locks, Security > Reporter: Tristan Tarrant > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Final > > > DistributedLocks should support authorization. > Namely only ADMIN permissions should be allowed to defineLocks and WRITE permissions should be allowed to manipulate them. > When authorization is enabled, the DistributedLockManager should return SecureClusteredLocks which verify that the user has the required privileges. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8491) Add streaming variant of off heap to not create byte[] instances

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8491?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8491: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > Add streaming variant of off heap to not create byte[] instances > ---------------------------------------------------------------- > > Key: ISPN-8491 > URL: https://issues.jboss.org/browse/ISPN-8491 > Project: Infinispan > Issue Type: Sub-task > Components: Off Heap > Reporter: William Burns > Priority: Major > Fix For: 10.0.0.Final > > > Currently off heap has to create a byte[] to copy memory from off heap. This is a waste of CPU and memory to do so. Instead we should have a streaming variant Output that the GlobalMarshaller can use that doesn't need all of this unnecessary copying. Unfortunately GlobalMarshaller is currently internally hard coded to require the usage of byte[] so we would have to tweak some code there as well to allow this. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8513) DistSyncOnePhaseTxStateTransferTest random failures

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8513?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8513: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > DistSyncOnePhaseTxStateTransferTest random failures > --------------------------------------------------- > > Key: ISPN-8513 > URL: https://issues.jboss.org/browse/ISPN-8513 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Alpha2 > Reporter: Pedro Ruivo > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Final > > Attachments: DistSyncOnePhaseTxStateTransferTest_pr_wburns_offheap_singlenode2_20171030.log.gz > > > {{DistSyncOnePhaseTxStateTransferTest}} sometimes asserts that the x-site transfer has finished in the remote site too early: > {noformat} > 17:34:38,464 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.xsite.statetransfer.DistSyncOnePhaseTxStateTransferTest.testCancelStateTransfer[null, tx=false] > java.lang.AssertionError: > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49) ~[testng-6.8.8.jar:?] > at org.infinispan.xsite.statetransfer.BaseStateTransferTest$20.assertInCache(BaseStateTransferTest.java:601) ~[test-classes/:?] > at org.infinispan.xsite.AbstractXSiteTest.assertInSite(AbstractXSiteTest.java:172) ~[test-classes/:?] > at org.infinispan.xsite.statetransfer.BaseStateTransferTest.assertNoStateTransferInReceivingSite(BaseStateTransferTest.java:596) ~[test-classes/:?] > at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testCancelStateTransfer(BaseStateTransferTest.java:141) ~[test-classes/:?] > {noformat} > In fact, this part of the test seems to let the state transfer finish normally instead of cancelling it, so it could use some logs/comments to explain what's going on. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8487) Global MBean registration happens too soon

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8487?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8487: ---------------------------------- Fix Version/s: 10.0.0.Final (was: 9.4.8.Final) > Global MBean registration happens too soon > ------------------------------------------ > > Key: ISPN-8487 > URL: https://issues.jboss.org/browse/ISPN-8487 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Alpha2 > Reporter: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > Currently {{DefaultCacheManager}} explicitly starts {{CacheManagerJmxRegistration}} before calling {{ModuleLifecycle#cacheManagerStarting}}, which means MBeans in other modules are not registered in JMX. > We should start {{CacheManagerJmxRegistration}} only during global component registry start, after the modules have registered their components. If we want to make the cache manager available in JMX before {{DefaultCacheManager.start()}}, we should only register that particular MBean. Conversely, on shutdown, components other than the cache manager should be removed from JMX on {{DefaultCacheManager.stop()}} (as per ISPN-118). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 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 February 2019