[JBoss JIRA] (ISPN-11636) Remove node suspected error code from Hot Rod protocol
by Dan Berindei (Jira)
Dan Berindei created ISPN-11636:
-----------------------------------
Summary: Remove node suspected error code from Hot Rod protocol
Key: ISPN-11636
URL: https://issues.redhat.com/browse/ISPN-11636
Project: Infinispan
Issue Type: Task
Components: Hot Rod
Affects Versions: 11.0.0.Dev04
Reporter: Dan Berindei
Fix For: 11.0.0.Final
Hot Rod 2.0 introduced error code {{0x87}} for the client to retry when another node has been suspected. However, the server is already handling the retry itself since ISPN-3366/ISPN-4546, so the client should never receive error code {{0x87}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months
[JBoss JIRA] (ISPN-11635) HotRod client testsuite leaves index folders behind
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11635?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11635:
-------------------------------------
Status: Open (was: New)
> HotRod client testsuite leaves index folders behind
> ---------------------------------------------------
>
> Key: ISPN-11635
> URL: https://issues.redhat.com/browse/ISPN-11635
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> {noformat}
> ➜ hotrod-client git:(clean_index) ✗ gss
> ?? alreadyExistingCacheTest_protobuf/
> ?? cacheCreateRemoveTestWithDefaultTemplateEnum_protobuf/
> ?? cacheCreateRemoveTest_protobuf/
> ?? cacheReindexTest_protobuf/
> ?? default_protobuf/
> ?? getOrCreateWithTemplateTest_protobuf/
> ?? testGetCacheNames_protobuf/
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months
[JBoss JIRA] (ISPN-11635) HotRod client testsuite leaves index folders behind
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11635?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11635:
-------------------------------------
Summary: HotRod client testsuite leaves index folders behind (was: HotRod client testsuite leaves index folders behing)
> HotRod client testsuite leaves index folders behind
> ---------------------------------------------------
>
> Key: ISPN-11635
> URL: https://issues.redhat.com/browse/ISPN-11635
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> {noformat}
> ➜ hotrod-client git:(clean_index) ✗ gss
> ?? alreadyExistingCacheTest_protobuf/
> ?? cacheCreateRemoveTestWithDefaultTemplateEnum_protobuf/
> ?? cacheCreateRemoveTest_protobuf/
> ?? cacheReindexTest_protobuf/
> ?? default_protobuf/
> ?? getOrCreateWithTemplateTest_protobuf/
> ?? testGetCacheNames_protobuf/
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months
[JBoss JIRA] (ISPN-11635) HotRod client testsuite leaves index folders behing
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPN-11635:
----------------------------------------
Summary: HotRod client testsuite leaves index folders behing
Key: ISPN-11635
URL: https://issues.redhat.com/browse/ISPN-11635
Project: Infinispan
Issue Type: Bug
Components: Remote Querying
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
{noformat}
➜ hotrod-client git:(clean_index) ✗ gss
?? alreadyExistingCacheTest_protobuf/
?? cacheCreateRemoveTestWithDefaultTemplateEnum_protobuf/
?? cacheCreateRemoveTest_protobuf/
?? cacheReindexTest_protobuf/
?? default_protobuf/
?? getOrCreateWithTemplateTest_protobuf/
?? testGetCacheNames_protobuf/
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months
[JBoss JIRA] (ISPN-11620) Remove EncoderRegistry from DataConversion
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11620?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11620:
-------------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/8196
> Remove EncoderRegistry from DataConversion
> -------------------------------------------
>
> Key: ISPN-11620
> URL: https://issues.redhat.com/browse/ISPN-11620
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 11.0.0.Dev03
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> The DataConversion carries an instance of EncodingRegistry, and exports operations that use it internally:
> * isConversionSupported(MediaType mediaType)
> * convert(Object o, MediaType from, MediaType to)
> * convertToRequestFormat(Object o, MediaType contentType)
> Those operations should be removed and moved to the EncoderRegistry itself, freeing the DataConversion objects from maintaining an internal reference to the registry. This also solves the issue of static DataContainer objects being used in mulitple nodes in the same JVM
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months
[JBoss JIRA] (ISPN-11634) Merge TopologyUpdateStableCommand and TopologyUpdateCommand
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11634?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-11634:
--------------------------------
Summary: Merge TopologyUpdateStableCommand and TopologyUpdateCommand (was: Merge StableTopologyUpdateCommand and TopologyUpdateCommand)
> Merge TopologyUpdateStableCommand and TopologyUpdateCommand
> -----------------------------------------------------------
>
> Key: ISPN-11634
> URL: https://issues.redhat.com/browse/ISPN-11634
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Dev04
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Dev05
>
>
> {code:java}
> 19:48:14,672 TRACE (testng-Test:[]) [TopologyManagementHelper] Attempting to execute command on self: StableTopologyUpdateCommand{cacheName='testCache', origin=Test-NodeD, currentCH=DefaultConsistentHash
> {ns=256, owners = (1)[Test-NodeE: 256+0]}
> , pendingCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342], rebalanceId=5, topologyId=27, viewId=7}
> 19:48:14,686 INFO (jgroups-5,Test-NodeE:[]) [CLUSTER] ISPN000094: Received new cluster view for channel org.infinispan.statetransfer.Test: [Test-NodeE|8] (1) [Test-NodeE]
> 19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max stable partition topology: CacheTopology{id=25, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash
> {ns=256, owners = (2)[Test-NodeD: 129+127, Test-NodeE: 127+129]}
> , pendingCH=null, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE], persistentUUIDs=[099401f9-c0b6-460d-8dc8-5051699e8287, 72b17309-62d1-4928-abf6-88a8606ef342]}
> 19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max active partition topology: CacheTopology{id=27, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash
> {ns=256, owners = (1)[Test-NodeE: 256+0]}
> , pendingCH=null, unionCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342]}
> 19:48:14,690 DEBUG (non-blocking-thread-Test-NodeE-p9541-t3:[]) [LocalTopologyManagerImpl] Ignoring topology 27 for cache testCache from old coordinator Test-NodeD
> {code}
> The old coordinator (NodeD) sent the topology update and the stable topology update, and NodeE received both. However NodeE might ignores the stable topology update because it was processed after it got the new cluster view, with itself as the coordinator. The proper fix is to get rid of the StableTopologyUpdateCommand and add a stable=true/false field in CacheTopology or in TopologyUpdateCommand.
> There's still a small chance that the coordinator will shut down before sending the topology update command to any of the other nodes, but it's a small chance. It's much more likely that a separate stable topology update command will be ignored because it is queued by LocalTopologyManagerImpl after the regular topology update command, and the regular topology update has a lot of processing to do in StateConsumerImpl.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months
[JBoss JIRA] (ISPN-11634) Merge StableTopologyUpdateCommand and TopologyUpdateCommand
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-11634:
-----------------------------------
Summary: Merge StableTopologyUpdateCommand and TopologyUpdateCommand
Key: ISPN-11634
URL: https://issues.redhat.com/browse/ISPN-11634
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 11.0.0.Dev04
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 11.0.0.Dev05
{code:java}
19:48:14,672 TRACE (testng-Test:[]) [TopologyManagementHelper] Attempting to execute command on self: StableTopologyUpdateCommand{cacheName='testCache', origin=Test-NodeD, currentCH=DefaultConsistentHash
{ns=256, owners = (1)[Test-NodeE: 256+0]}
, pendingCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342], rebalanceId=5, topologyId=27, viewId=7}
19:48:14,686 INFO (jgroups-5,Test-NodeE:[]) [CLUSTER] ISPN000094: Received new cluster view for channel org.infinispan.statetransfer.Test: [Test-NodeE|8] (1) [Test-NodeE]
19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max stable partition topology: CacheTopology{id=25, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash
{ns=256, owners = (2)[Test-NodeD: 129+127, Test-NodeE: 127+129]}
, pendingCH=null, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE], persistentUUIDs=[099401f9-c0b6-460d-8dc8-5051699e8287, 72b17309-62d1-4928-abf6-88a8606ef342]}
19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max active partition topology: CacheTopology{id=27, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash
{ns=256, owners = (1)[Test-NodeE: 256+0]}
, pendingCH=null, unionCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342]}
19:48:14,690 DEBUG (non-blocking-thread-Test-NodeE-p9541-t3:[]) [LocalTopologyManagerImpl] Ignoring topology 27 for cache testCache from old coordinator Test-NodeD
{code}
The old coordinator (NodeD) sent the topology update and the stable topology update, and NodeE received both. However NodeE might ignores the stable topology update because it was processed after it got the new cluster view, with itself as the coordinator. The proper fix is to get rid of the StableTopologyUpdateCommand and add a stable=true/false field in CacheTopology or in TopologyUpdateCommand.
There's still a small chance that the coordinator will shut down before sending the topology update command to any of the other nodes, but it's a small chance. It's much more likely that a separate stable topology update command will be ignored because it is queued by LocalTopologyManagerImpl after the regular topology update command, and the regular topology update has a lot of processing to do in StateConsumerImpl.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months
[JBoss JIRA] (ISPN-11566) StatefulSetRollingUpgradeTest failing on CI
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11566?page=com.atlassian.jira.plugi... ]
Ryan Emerson commented on ISPN-11566:
-------------------------------------
Dan: @Ryan Emerson this is what I got from the log:
19:48:14,672 TRACE (testng-Test:[]) [TopologyManagementHelper] Attempting to execute command on self: StableTopologyUpdateCommand{cacheName='testCache', origin=Test-NodeD, currentCH=DefaultConsistentHash{ns=256, owners = (1)[Test-NodeE: 256+0]}, pendingCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342], rebalanceId=5, topologyId=27, viewId=7}
19:48:14,686 INFO (jgroups-5,Test-NodeE:[]) [CLUSTER] ISPN000094: Received new cluster view for channel org.infinispan.statetransfer.Test: [Test-NodeE|8] (1) [Test-NodeE]
19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max stable partition topology: CacheTopology{id=25, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash{ns=256, owners = (2)[Test-NodeD: 129+127, Test-NodeE: 127+129]}, pendingCH=null, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE], persistentUUIDs=[099401f9-c0b6-460d-8dc8-5051699e8287, 72b17309-62d1-4928-abf6-88a8606ef342]}
19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max active partition topology: CacheTopology{id=27, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash{ns=256, owners = (1)[Test-NodeE: 256+0]}, pendingCH=null, unionCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342]}
Dan: The old coordinator (NodeD) sent the topology update and the stable topology update, and NodeE received both
Dan: But NodeE might have ignored the stable topology update because it was processed after it got the new cluster view, with itself as the coordinator
Dan: Although I need to look further, because I don't see any log about ignoring the stable topology update
Dan: The proper fix is probably to get rid of the StableTopologyUpdateCommand
Dan: And either compute deterministically whether a cache topology is stable or not on each node, based on the phase and actual members
Dan: Or add a stable=true/false field in CacheTopology or in TopologyUpdateCommand
Dan: I've been thinking about doing this for a while, but I don't remember if I ever got so far as to create a JIRA
Dan: I found the ignore log:
19:48:14,690 DEBUG (non-blocking-thread-Test-NodeE-p9541-t3:[]) [LocalTopologyManagerImpl] Ignoring topology 27 for cache testCache from old coordinator Test-NodeD
Dan: There's still a small chance that the coordinator will shut down before sending the topology update command to any of the other nodes, but it's a small chance
Dan: It's much more likely that a separate stable topology update command will be ignored because it is queued by LocalTopologyManagerImpl after the regular topology update command, and the regular topology update has a lot of processing to do in StateConsumerImpl
Dan: Very similar to ISPN-9270
Ryan Emerson: Thanks for looking into this @Dan
Ryan Emerson: I think removing the stable update command utilising a boolean in TopologyUpdateCommand is probably the simplest solution
Ryan Emerson: deterministically computing the stable topology seems like their might be a few gotchas (gut feeling, I haven't properly thought about it)
Ryan Emerson: We could always update TopologyUpdateCommand and then investigate the latter if there is time in 11.x
Dan: +1
> StatefulSetRollingUpgradeTest failing on CI
> -------------------------------------------
>
> Key: ISPN-11566
> URL: https://issues.redhat.com/browse/ISPN-11566
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Dev03
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months
[JBoss JIRA] (ISPN-11426) Add UUID to core SerializationContexts
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11426?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-11426:
--------------------------------
Description: Currently we only register a ProtoStream marshaller for java.util.UUID in the server as they are required for the event logger, however this will also be required by core for `MultiClusterEventCommand` and `ClusterEvent`. It's not possible to register a class in multiple contexts when utilising a TypeId, therefore in order to avoid having to provide a TypeId for UUIDs in both core and server, we should register this in the core's persistence initializers. (was: Currently we only register a ProtoStream marshaller for java.util.UUID in the server as they are required for the event logger, however this will also be required by core for `MultiClusterEventCommand` and `ClusterEvent`. It's not possible to register a class in multiple contexts when utilising a TypeId, therefore in order to avoid having to provide a TypeId for UUIDs in both core and server, we should register this in the core's persistence initializers. A flip-side to this is that it will also mean that UUIDs will be supported by default in embedded mode.)
> Add UUID to core SerializationContexts
> --------------------------------------
>
> Key: ISPN-11426
> URL: https://issues.redhat.com/browse/ISPN-11426
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.1.3.Final, 11.0.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> Currently we only register a ProtoStream marshaller for java.util.UUID in the server as they are required for the event logger, however this will also be required by core for `MultiClusterEventCommand` and `ClusterEvent`. It's not possible to register a class in multiple contexts when utilising a TypeId, therefore in order to avoid having to provide a TypeId for UUIDs in both core and server, we should register this in the core's persistence initializers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 12 months