[JBoss JIRA] (ISPN-8973) Administration console - changing eviction strategy results in error
by Roman Macor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8973?page=com.atlassian.jira.plugin.... ]
Roman Macor commented on ISPN-8973:
-----------------------------------
[~vblagojevic] I'm sorry, the fourth step should be restart later (instead of restart now). My mistake.
I've tested it with 9.2.1-SNAPSHOT - last commit ISPN-8935 AbstractFileLookup.lookupFileStrict does not work for jar scheme
> Administration console - changing eviction strategy results in error
> --------------------------------------------------------------------
>
> Key: ISPN-8973
> URL: https://issues.jboss.org/browse/ISPN-8973
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.2.0.Final
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
>
> Steps to reproduce:
> - start server in domain mode
> - click on cache container -> cache -> configuration -> memory tab -> set memory
> - e.g. (Type: binary, Eviction: count, Size: 10, strategy: FIFO)
> - apply changes -> restart now
> - change the strategy to LRU, click apply changes
> That results in error popup:
> {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:":{"server-group":{"cluster":{"host":{"master":{"server-one":{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:":{"Operation step-3":"WFLYCTL0158: Operation handler failed: java.lang.NullPointerException"}},"server-two":{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:":{"Operation step-3":"WFLYCTL0158: Operation handler failed: java.lang.NullPointerException"}}}}}}}}
> There are no error logs in the server log.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9027) Distinguishing different Cache Store configurations is impossible
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-9027?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-9027:
----------------------------------
Assignee: Ryan Emerson
> Distinguishing different Cache Store configurations is impossible
> -----------------------------------------------------------------
>
> Key: ISPN-9027
> URL: https://issues.jboss.org/browse/ISPN-9027
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.2.1.Final
> Reporter: Sebastian Łaskawiec
> Assignee: Ryan Emerson
> Attachments: clustered.xml
>
>
> h3. Problem description
> One of our users reported that when using two Deployed Cache Stores, their configuration gets overridden and both behaves as if they had the same configuration. Here's an example:
> {code}
> <distributed-cache name="cassandracache1" owners="2" segments="256" mode="SYNC">
> <store name="store1" class="org.infinispan.persistence.cassandra.CassandraStore" preload="true">
> <property name="autoCreateKeyspace">
> true
> </property>
> <property name="keyspace">
> Infinispan
> </property>
> <property name="entryTable">
> InfinispanEntries
> </property>
> <property name="servers">
> 172.17.0.2[9042]
> </property>
> </store>
> </distributed-cache>
> <distributed-cache name="cassandracache2" owners="2" segments="256" mode="SYNC">
> <store name="store2" class="org.infinispan.persistence.cassandra.CassandraStore" preload="true">
> <property name="autoCreateKeyspace">
> true
> </property>
> <property name="keyspace">
> Infinispan
> </property>
> <property name="entryTable">
> InfinispanEntries1
> </property>
> <property name="servers">
> 172.17.0.2[9042]
> </property>
> </store>
> </distributed-cache>
> {code}
> Both caches ({{cassandracache1}} and {{cassandracache2}}) use the same {{entryTable}} which is set to {{InfinispanEntries1}}.
> h3. Investigation
> {{CacheStoreFactory}} implementation were created to fabricate Loader/Writer instance based on parsed configuration (via {{createInstance}} method). This method receives from {{PersistenceManagerImpl}} an instance of an {{AbstractStoreConfiguration}} (here's an example (1)) two times - once per each parsed configuration. The parsing part seems OK but we do not parse Cache Store Name, which makes differentiating both configuration impossible.
> h3. Proposed fix
> * Add {{name}} attribute to {{StoreConfiguration}}.
> * Either add an explicit parameter to {{CacheStoreFactory#createInstance(StoreConfiguration cfg, String cacheStoreName)}} or scan for Cache Store name in both implementations ({{DeployedCacheStoreFactory}} and {{LocalClassLoaderCacheStoreFactory}}.
> {code}
> (1) AbstractStoreConfiguration [attributes=DeployedStoreConfiguration = [fetchPersistentState=false, purgeOnStartup=false, ignoreModifications=false, preload=true, shared=false, transactional=false, maxBatchSize=100, properties={keyspace=Infinispan, connectionPool.poolTimeoutMillis=5, entryTable=InfinispanEntries, connectionPool.idleTimeoutSeconds=120, connectionPool.heartbeatIntervalSeconds=30, autoCreateKeyspace=true, servers=172.17.0.2[9042]}, customStoreClassName=org.infinispan.persistence.cassandra.CassandraStore], async=AsyncStoreConfiguration [attributes=AsyncStoreConfiguration = [enabled=false, modificationQueueSize=1024, threadPoolSize=1]], singletonStore=SingletonStoreConfiguration [attributes=SingletonStoreConfiguration = [enabled=false, push-state-timeout=10000, push-state-when-coordinator=true]]]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-8903) Conflict resolution not initiated if node rejoins with same topology
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8903?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-8903:
------------------------------------
[~dan.berindei] Wouldn't this undermine the purpose of having EntryMergePolicy implementations? Because ultimately if a conflict has occurred, surely we should always rely on the policies semantics, otherwise this would be very confusing to the user.
> Conflict resolution not initiated if node rejoins with same topology
> --------------------------------------------------------------------
>
> Key: ISPN-8903
> URL: https://issues.jboss.org/browse/ISPN-8903
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.1.Final, 9.3.0.Final
>
>
> The current logic in PreferAvailabilityStrategy and PreferConsistencyStrategy assumes that when a split brain occurs, the two partitions will continue to operate independently before a merge occurs.
> Consider a cluster \{A,B\} which partitions into P1 \{A\} and P2 \{B\}. P1 continues to operate and update cache entries, however P2 makes no progress (possibly down to a long GC pause). When P2 merges into P1, no conflict resolution occurs as the maxTopology contains all of the possible owners. Conflict resolution should be attempted in this scenario, as it's possible that entries have been put to P1 during the partition and therefore P2 will have stale values.
> This can be reproduced by creating two nodes, pausing one process, wait for split and then resuming the process. No CR will occur.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9033) Web/CLI hangs if cache use cache store and has a lot of entries
by Sergey Chernolyas (JIRA)
Sergey Chernolyas created ISPN-9033:
---------------------------------------
Summary: Web/CLI hangs if cache use cache store and has a lot of entries
Key: ISPN-9033
URL: https://issues.jboss.org/browse/ISPN-9033
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 9.2.1.Final
Reporter: Sergey Chernolyas
Priority: Blocker
My cache configuration has RocksDB's cache. Cache has a more then 1 000 000 entries.
And it do usage of Web interfce and CLI impossible.
As I have investigated, problem can be in class org.infinispan.commands.read.SizeCommand.
{code:java}
public Integer perform(InvocationContext ctx) throws Throwable {
long size = cache.keySet().stream().count();
if (size > Integer.MAX_VALUE) {
return Integer.MAX_VALUE;
} else {
return (int) size;
}
}
{code}
I think, the code must ask CacheStore for sizing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9032) OperationsDuringMergeConflictTest.testPartitionMergePolicy random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9032?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9032:
-------------------------------
Status: Open (was: New)
> OperationsDuringMergeConflictTest.testPartitionMergePolicy random failures
> --------------------------------------------------------------------------
>
> Key: ISPN-9032
> URL: https://issues.jboss.org/browse/ISPN-9032
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Labels: testsuite_stability
> Fix For: 9.3.0.Alpha1
>
>
> The test modifies a key in both partitions and checks that each partition still sees its own value for a while after receiving the [merged cluster view|https://github.com/infinispan/infinispan/blob/ee87349f0b134b53b3090f...].
> It installs a {{BlockStateResponseCommandHandler}} to block the conflict resolution responses and to keep the pre-merge values in the non-preferred topology owners. However, it does not block the installation of the {{CONFLICT_RESOLUTION}} cache topology. And during conflict resolution the read CH is the preferred topology's read CH, so non-preferred topology owners will ask the primary owner for the value:
> {noformat}
> 17:12:07,088 INFO (testng-Test:[]) [JGroupsTransport] ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[Test-NodeI-48950|10] (4) [Test-NodeI-48950, Test-NodeJ-6577, Test-NodeK-2872, Test-NodeL-23686], 2 subgroups: [Test-NodeI-48950|8] (2) [Test-NodeI-48950, Test-NodeJ-6577], [Test-NodeK-2872|9] (2) [Test-NodeK-2872, Test-NodeL-23686]
> 17:12:07,134 TRACE (stateTransferExecutor-thread-Test-NodeI-p50536-t2:[Merge-10]) [DefaultConflictManager] Cache ___defaultcache attempting to receive all replicas for segment 0 with topology CacheTopology{id=20, rebalanceId=7, currentCH=DefaultConsistentHash{ns=256, owners = (2)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134]}, pendingCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, unionCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, phase=CONFLICT_RESOLUTION, actualMembers=[Test-NodeK-2872, Test-NodeL-23686, Test-NodeI-48950, Test-NodeJ-6577], persistentUUIDs=[40b58191-37f1-4fa4-8e4b-f1a7c17bfa59, 208d742d-ecc9-4792-9dd5-f74d5666f5a2, d8914096-a5a4-4e1e-95a0-27c50fee9999, 7464e58b-5e23-4c1b-909e-4e53055f12ca]}
> 17:12:07,212 TRACE (testng-Test:[]) [BaseDistributionInterceptor] Perform remote get for key MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}. currentTopologyId=20, owners=[Test-NodeK-2872, Test-NodeL-23686]
> 17:12:07,212 TRACE (testng-Test:[]) [RpcManagerImpl] Test-NodeI-48950 invoking ClusteredGetCommand{key=MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}, flags=[]} to recipient list [Test-NodeK-2872, Test-NodeL-23686] with options RpcOptions{timeout=15000, unit=MILLISECONDS, deliverOrder=NONE, responseFilter=org.infinispan.interceptors.impl.BaseRpcInterceptor$1@241e783a, responseMode=WAIT_FOR_VALID_RESPONSE}
> 17:12:07,225 TRACE (jgroups-4,Test-NodeI-48950:[]) [CommandAwareRpcDispatcher] Got acceptable response: Responses{
> Test-NodeK-2872: value=SuccessfulResponse{responseValue=ImmortalCacheValue {value=B}} , received=true, suspected=false
> 17:12:07,226 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.conflict.impl.OperationsDuringMergeConflictTest.testPartitionMergePolicy
> java.lang.AssertionError: Key=MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}, Value=A, Cache Index=0, Topology=CacheTopology{id=20, rebalanceId=7, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (2)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134]}, pendingCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, unionCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, phase=CONFLICT_RESOLUTION, actualMembers=[Test-NodeK-2872, Test-NodeL-23686, Test-NodeI-48950, Test-NodeJ-6577], persistentUUIDs=[40b58191-37f1-4fa4-8e4b-f1a7c17bfa59, 208d742d-ecc9-4792-9dd5-f74d5666f5a2, d8914096-a5a4-4e1e-95a0-27c50fee9999, 7464e58b-5e23-4c1b-909e-4e53055f12ca]} expected:<A> but was:<B>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?]
> at org.infinispan.conflict.impl.BaseMergePolicyTest.assertCacheGet(BaseMergePolicyTest.java:160) ~[test-classes/:?]
> at org.infinispan.conflict.impl.OperationsDuringMergeConflictTest.performMerge(OperationsDuringMergeConflictTest.java:121) ~[test-classes/:?]
> at org.infinispan.conflict.impl.BaseMergePolicyTest.testPartitionMergePolicy(BaseMergePolicyTest.java:116) ~[test-classes/:?]
> {noformat}
> https://ci.infinispan.org/job/Infinispan/job/master/543/testReport/org.in...
> Maybe we should use the union CH for reading during conflict resolution instead?
> Speaking of which, {{PreferAvailabilityStrategy}} sets the {{unionCH}} field in the conflict resolution {{CacheTopology}}, but it is ignored because {{CacheTopologyControlCommand}} doesn't have a field for it. We should set {{unionCH=null}} in {{PreferAvailabilityStrategy}} to make things clearer. We should also try to reduce the number of times we log the cache topology during conflict resolution (even if it's only at trace level).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9032) OperationsDuringMergeConflictTest.testPartitionMergePolicy random failures
by Dan Berindei (JIRA)
Dan Berindei created ISPN-9032:
----------------------------------
Summary: OperationsDuringMergeConflictTest.testPartitionMergePolicy random failures
Key: ISPN-9032
URL: https://issues.jboss.org/browse/ISPN-9032
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 9.2.1.Final
Reporter: Dan Berindei
Assignee: Ryan Emerson
Fix For: 9.3.0.Alpha1
The test modifies a key in both partitions and checks that each partition still sees its own value for a while after receiving the [merged cluster view|https://github.com/infinispan/infinispan/blob/ee87349f0b134b53b3090f...].
It installs a {{BlockStateResponseCommandHandler}} to block the conflict resolution responses and to keep the pre-merge values in the non-preferred topology owners. However, it does not block the installation of the {{CONFLICT_RESOLUTION}} cache topology. And during conflict resolution the read CH is the preferred topology's read CH, so non-preferred topology owners will ask the primary owner for the value:
{noformat}
17:12:07,088 INFO (testng-Test:[]) [JGroupsTransport] ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[Test-NodeI-48950|10] (4) [Test-NodeI-48950, Test-NodeJ-6577, Test-NodeK-2872, Test-NodeL-23686], 2 subgroups: [Test-NodeI-48950|8] (2) [Test-NodeI-48950, Test-NodeJ-6577], [Test-NodeK-2872|9] (2) [Test-NodeK-2872, Test-NodeL-23686]
17:12:07,134 TRACE (stateTransferExecutor-thread-Test-NodeI-p50536-t2:[Merge-10]) [DefaultConflictManager] Cache ___defaultcache attempting to receive all replicas for segment 0 with topology CacheTopology{id=20, rebalanceId=7, currentCH=DefaultConsistentHash{ns=256, owners = (2)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134]}, pendingCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, unionCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, phase=CONFLICT_RESOLUTION, actualMembers=[Test-NodeK-2872, Test-NodeL-23686, Test-NodeI-48950, Test-NodeJ-6577], persistentUUIDs=[40b58191-37f1-4fa4-8e4b-f1a7c17bfa59, 208d742d-ecc9-4792-9dd5-f74d5666f5a2, d8914096-a5a4-4e1e-95a0-27c50fee9999, 7464e58b-5e23-4c1b-909e-4e53055f12ca]}
17:12:07,212 TRACE (testng-Test:[]) [BaseDistributionInterceptor] Perform remote get for key MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}. currentTopologyId=20, owners=[Test-NodeK-2872, Test-NodeL-23686]
17:12:07,212 TRACE (testng-Test:[]) [RpcManagerImpl] Test-NodeI-48950 invoking ClusteredGetCommand{key=MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}, flags=[]} to recipient list [Test-NodeK-2872, Test-NodeL-23686] with options RpcOptions{timeout=15000, unit=MILLISECONDS, deliverOrder=NONE, responseFilter=org.infinispan.interceptors.impl.BaseRpcInterceptor$1@241e783a, responseMode=WAIT_FOR_VALID_RESPONSE}
17:12:07,225 TRACE (jgroups-4,Test-NodeI-48950:[]) [CommandAwareRpcDispatcher] Got acceptable response: Responses{
Test-NodeK-2872: value=SuccessfulResponse{responseValue=ImmortalCacheValue {value=B}} , received=true, suspected=false
17:12:07,226 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.conflict.impl.OperationsDuringMergeConflictTest.testPartitionMergePolicy
java.lang.AssertionError: Key=MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}, Value=A, Cache Index=0, Topology=CacheTopology{id=20, rebalanceId=7, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (2)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134]}, pendingCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, unionCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, phase=CONFLICT_RESOLUTION, actualMembers=[Test-NodeK-2872, Test-NodeL-23686, Test-NodeI-48950, Test-NodeJ-6577], persistentUUIDs=[40b58191-37f1-4fa4-8e4b-f1a7c17bfa59, 208d742d-ecc9-4792-9dd5-f74d5666f5a2, d8914096-a5a4-4e1e-95a0-27c50fee9999, 7464e58b-5e23-4c1b-909e-4e53055f12ca]} expected:<A> but was:<B>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?]
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?]
at org.infinispan.conflict.impl.BaseMergePolicyTest.assertCacheGet(BaseMergePolicyTest.java:160) ~[test-classes/:?]
at org.infinispan.conflict.impl.OperationsDuringMergeConflictTest.performMerge(OperationsDuringMergeConflictTest.java:121) ~[test-classes/:?]
at org.infinispan.conflict.impl.BaseMergePolicyTest.testPartitionMergePolicy(BaseMergePolicyTest.java:116) ~[test-classes/:?]
{noformat}
https://ci.infinispan.org/job/Infinispan/job/master/543/testReport/org.in...
Maybe we should use the union CH for reading during conflict resolution instead?
Speaking of which, {{PreferAvailabilityStrategy}} sets the {{unionCH}} field in the conflict resolution {{CacheTopology}}, but it is ignored because {{CacheTopologyControlCommand}} doesn't have a field for it. We should set {{unionCH=null}} in {{PreferAvailabilityStrategy}} to make things clearer. We should also try to reduce the number of times we log the cache topology during conflict resolution (even if it's only at trace level).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9031) Add CodedInputStream.setsize functionality
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-9031?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-9031:
--------------------------------
Status: Open (was: New)
> Add CodedInputStream.setsize functionality
> ------------------------------------------
>
> Key: ISPN-9031
> URL: https://issues.jboss.org/browse/ISPN-9031
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Lena Herrmann
>
> 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.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9031) Add CodedInputStream.setsize functionality
by Lena Herrmann (JIRA)
Lena Herrmann created ISPN-9031:
-----------------------------------
Summary: Add CodedInputStream.setsize functionality
Key: ISPN-9031
URL: https://issues.jboss.org/browse/ISPN-9031
Project: Infinispan
Issue Type: Feature Request
Reporter: Lena Herrmann
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.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9030) Avoid anonymous classes inside lambdas
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-9030?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-9030:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated in master. Thanks [~dan.berindei]!
> Avoid anonymous classes inside lambdas
> --------------------------------------
>
> Key: ISPN-9030
> URL: https://issues.jboss.org/browse/ISPN-9030
> Project: Infinispan
> Issue Type: Task
> Components: Build
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 9.3.0.Alpha1
>
>
> IntelliJ's incremental compilation sometimes breaks down when recompiling an [anonymous class declared inside a lambda|https://youtrack.jetbrains.com/issue/IDEA-177431]:
> {noformat}
> Error:java: cannot access org.infinispan.query.dsl.embedded.impl.HibernateSearchPropertyHelper$2
> bad class file: /home/dan/Work/jdg/query/target/classes/org/infinispan/query/dsl/embedded/impl/HibernateSearchPropertyHelper$2.class
> bad enclosing method attribute for class org.infinispan.query.dsl.embedded.impl.HibernateSearchPropertyHelper$2
> Please remove or make sure it appears in the correct subdirectory of the classpath.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years