October 2018 - infinispan-issues - Jboss List Archives

[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: 9.4.2.Final (was: 9.4.1.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: 9.4.2.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)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8192) Deprecate redundant methods in CollectionFactory

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8192?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8192: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Deprecate redundant methods in CollectionFactory > ------------------------------------------------ > > Key: ISPN-8192 > URL: https://issues.jboss.org/browse/ISPN-8192 > Project: Infinispan > Issue Type: Task > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.2.Final > > > Many of the methods in CollectionFactory are redundant and do not add any value. We should deprecate these and replace their use within our code. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8005) Document LockedStreams in User Guide

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8005?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8005: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Document LockedStreams in User Guide > ------------------------------------ > > Key: ISPN-8005 > URL: https://issues.jboss.org/browse/ISPN-8005 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 9.4.2.Final > > > LockedStreams needs to be documented in User Guide so users know how to use it! -- This message was sent by Atlassian Jira (v7.12.1#712002)

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

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.2.Final (was: 9.4.1.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.2.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-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.2.Final (was: 9.4.1.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 > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.2.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

[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.2.Final (was: 9.4.1.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.2.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-9031) Add CodedInputStream.setsize functionality

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9031?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9031: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Add CodedInputStream.setsize functionality > ------------------------------------------ > > Key: ISPN-9031 > URL: https://issues.jboss.org/browse/ISPN-9031 > Project: Infinispan > Issue Type: Feature Request > Reporter: Lena Herrmann > Priority: Major > Fix For: 9.4.2.Final > > > If you want to use the Protobufmarchaller for larger objects the following exception occurs: > {code:java} > at org.infinispan.client.hotrod.marshall.MarshallerUtil.bytes2obj(MarshallerUtil.java:49) > at org.infinispan.client.hotrod.impl.protocol.CodecUtils.readUnmarshallByteArray(CodecUtils.java:38) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readUnmarshallByteArray(Codec20.java:54) > at org.infinispan.client.hotrod.impl.operations.GetOperation.executeOperation(GetOperation.java:36) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:367) > at com.channelpilot.api.tabledata.RemoteCacheConnector.get(RemoteCacheConnector.java:49) > at com.channelpilot.api.tabledata.TableDataService.get(TableDataService.java:91) > at com.channelpilot.api.tabledata.build.ControlDataBuilder.build(ControlDataBuilder.java:48) > at com.channelpilot.api.frontend.jobs.threads.BuildTableDataJob.execute(BuildTableDataJob.java:72) > at com.channelpilot.api.frontend.jobs.threads.BuildTableDataJob.execute(BuildTableDataJob.java:31) > at com.channelpilot.utils.concurrent.CPCallable.call(CPCallable.java:105) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: protostream.com.google.protobuf.InvalidProtocolBufferException: Protocol message was too large. May be malicious. Use CodedInputStream.setSizeLimit() to increase the size limit. > at protostream.com.google.protobuf.InvalidProtocolBufferException.sizeLimitExceeded(InvalidProtocolBufferException.java:122) > at protostream.com.google.protobuf.CodedInputStream.readRawBytesSlowPath(CodedInputStream.java:1166) > at protostream.com.google.protobuf.CodedInputStream.readByteArray(CodedInputStream.java:535) > at org.infinispan.protostream.impl.RawProtoStreamReaderImpl.readByteArray(RawProtoStreamReaderImpl.java:105) > at org.infinispan.protostream.WrappedMessage.readMessage(WrappedMessage.java:232) > at org.infinispan.protostream.ProtobufUtil.fromWrappedByteArray(ProtobufUtil.java:122) > at org.infinispan.query.remote.client.BaseProtoStreamMarshaller.objectFromByteBuffer(BaseProtoStreamMarshaller.java:32) > at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82) > at org.infinispan.client.hotrod.marshall.MarshallerUtil.bytes2obj(MarshallerUtil.java:33) > {code} > According to the official protobuf-documentation one should increase the size-limit, if this exception is thrown. Within infinispan there is no possibility to change this size in some way. > Adding the to for example a configurationbuilder or similar, would be a good improvement. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9029) Add test for exception eviction dropping entries after node leave

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9029?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9029: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Add test for exception eviction dropping entries after node leave > ----------------------------------------------------------------- > > Key: ISPN-9029 > URL: https://issues.jboss.org/browse/ISPN-9029 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: William Burns > Priority: Major > Fix For: 9.4.2.Final > > > {{ExceptionEvictionTest}} tests what happens when a node is added and N*limit existing entries are redistributed among N+1 nodes. We also need to test what happens when a node crashes and N*limit entries are redistributed among N-1 nodes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9028) Write-only segments should be invalidated during the READ_NEW phase

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9028?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9028: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Write-only segments should be invalidated during the READ_NEW phase > ------------------------------------------------------------------- > > Key: ISPN-9028 > URL: https://issues.jboss.org/browse/ISPN-9028 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 9.4.2.Final > > > When a rebalance removes a segment X from node A, node A keeps updating entries in segment X until the rebalance finishes, and only deletes the entries of segment X after entering the NO_REBALANCE phase. > This is problematic for tests that work with the data container directly, because {{waitForNoRebalance()}} doesn't wait for the removal of stale entries. The test will work without an explicit wait most of the time, so this is a recipe for random test failures (e.g. ISPN-8728). > As described in ISPN-5021, we can prevent any writes to segment X at the start of the READ_NEW_WRITE_ALL phase, send the phase confirmation to the coordinator, and then remove the entries asynchronously. We just need to keep track of the removal task and only install/confirm the NO_REBALANCE phase once all the entries that we don't own have been removed. -- 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 October 2018