November 2018 - infinispan-issues

[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: 9.4.4.Final (was: 9.4.3.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: 9.4.4.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)

5 years, 6 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: 9.4.4.Final (was: 9.4.3.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: 9.4.4.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 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: 9.4.4.Final (was: 9.4.3.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: 9.4.4.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)

5 years, 6 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: 9.4.4.Final (was: 9.4.3.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: 9.4.4.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)

5 years, 6 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: 9.4.4.Final (was: 9.4.3.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: 9.4.4.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)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9112) getCache() should not wait for the initial state transfer by default

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9112?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9112: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > getCache() should not wait for the initial state transfer by default > -------------------------------------------------------------------- > > Key: ISPN-9112 > URL: https://issues.jboss.org/browse/ISPN-9112 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.4.Final > > > {{DefaultCacheManager.getCache(name)}} normally blocks until the local node becomes a full member of the consistent hash and the rebalance has finished. This can cause problems when rebalancing is disabled, either explicitly by the administrator, or implicitly because the cache is in degraded mode. > Blocking can be disabled with {{builder.clustering().stateTransfer().awaitInitialTransfer(false)}} ({{await-initial-transfer="false"}} in XML}}, but we should make the non-blocking behaviour the default. We should also deprecate the method and attribute to enable the blocking behaviour, and instead add a method to {{AdvancedCache}} to wait for the initial state transfer. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9101) EncryptProtocolIT.testEncryptProtocolRegistered random failures

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9101?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9101: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > EncryptProtocolIT.testEncryptProtocolRegistered random failures > --------------------------------------------------------------- > > Key: ISPN-9101 > URL: https://issues.jboss.org/browse/ISPN-9101 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.4.4.Final > > > {noformat} > java.lang.RuntimeException: Could not retrieve HotRod host > at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:63) > Caused by: java.lang.IllegalArgumentException: Could not retrieve attribute HostName on MBean jboss.datagrid-infinispan:type=Server,name=HotRod,component=Transport > at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:63) > Caused by: javax.management.InstanceNotFoundException: jboss.datagrid-infinispan:type=Server,name=HotRod,component=Transport > {noformat} > The log shows this exception: > {noformat} > &amp#27;[0m&amp#27;[31m13:36:29,258 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.datagrid-jgroups.channel.cluster: org.jboss.msc.service.StartException in service jboss.datagrid-jgroups.channel.cluster: java.security.PrivilegedActionException: java.io.IOException: Invalid secret key format > at org.infinispan.server.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:79) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.security.PrivilegedActionException: java.io.IOException: Invalid secret key format > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:623) > at org.infinispan.server.jgroups.JChannelFactory.createChannel(JChannelFactory.java:104) > at org.infinispan.server.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:77) > ... 8 more > Caused by: java.io.IOException: Invalid secret key format > at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:856) > at java.security.KeyStore.load(KeyStore.java:1445) > at org.jgroups.protocols.SYM_ENCRYPT.readSecretKeyFromKeystore(SYM_ENCRYPT.java:97) > at org.jgroups.protocols.SYM_ENCRYPT.init(SYM_ENCRYPT.java:78) > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:840) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:479) > at org.jgroups.JChannel.init(JChannel.java:992) > at org.jgroups.JChannel.<init>(JChannel.java:148) > at org.infinispan.server.jgroups.JChannelFactory.lambda$createChannel$0(JChannelFactory.java:103) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) > ... 10 more > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9079) Cache operations during Conflict Resolution phase should force CR on that key

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9079?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9079: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Cache operations during Conflict Resolution phase should force CR on that key > ----------------------------------------------------------------------------- > > Key: ISPN-9079 > URL: https://issues.jboss.org/browse/ISPN-9079 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.4.Final > > > During a partition merge conflict resolution can take a long time when there are many entries, therefore if a user initiates an operation on a key during this phase, it should force CR to occur on the key before executing the operation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9072) Document Protobuf annotated collection null set callbacks

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9072?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9072: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Document Protobuf annotated collection null set callbacks > --------------------------------------------------------- > > Key: ISPN-9072 > URL: https://issues.jboss.org/browse/ISPN-9072 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Affects Versions: 9.2.1.Final > Reporter: Galder Zamarreño > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.4.Final > > > When using collection fields in Protobuf annotated classes, empty collections are marshalled into the same value as {{null}}, because Protobuf only has repeated fields and no fields is represented as {{null}}. > This means that if you have an entity with an empty collection, when it's deserialized the collection will be null. This can be confusing for users and should be documented. > [~anistor] had some ideas on how to improve this: > {code} > <anistor> I'm thinking of a way to make this easier for users that > would prefer an empty collection being set instead of a > null. would be possible by adding a new attribute for this in > @ProtoField anotation > > that'd be more predictable > <anistor> would still not give you at deserializtion what was written > during serialization. we do not have a null marker > <anistor> it would just give you an empty collection if you prefer > <anistor> instead of null > > that option should be enabled by default > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9054) Upgrade to Aesh 1.0

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9054?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9054: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Upgrade to Aesh 1.0 > ------------------- > > Key: ISPN-9054 > URL: https://issues.jboss.org/browse/ISPN-9054 > Project: Infinispan > Issue Type: Component Upgrade > Components: CLI > Reporter: Ryan Emerson > Priority: Major > Fix For: 9.4.4.Final > > > Aesh 1.0 has been released, and is currently used by Wildfly 12.x. 1.0 has several differences to Aesh 0.66.x, most notably the introduction of the aesh-readline project and the removal of AeshConsoleCallback. The upgrade is non-trivial, however due to some of the new features provided by Aesh 1.x, it could greatly reduce the amount of code required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2018