June 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11723) CLI: Cluster Backup/Restore Tool

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11723?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11723: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > CLI: Cluster Backup/Restore Tool > -------------------------------- > > Key: ISPN-11723 > URL: https://issues.redhat.com/browse/ISPN-11723 > Project: Infinispan > Issue Type: Enhancement > Components: CLI, Operator, Server > Affects Versions: 11.0.0.Dev04 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.0.0.Final > > > It should be possible to dump an entire contents cluster to an offline archive format, which can then be used to restore the content at a later time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11623) cli -c or --connect should use the default localhost:11222

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11623?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11623: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > cli -c or --connect should use the default localhost:11222 > ---------------------------------------------------------- > > Key: ISPN-11623 > URL: https://issues.redhat.com/browse/ISPN-11623 > Project: Infinispan > Issue Type: Enhancement > Components: CLI > Affects Versions: 10.1.5.Final > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Major > Fix For: 12.0.0.Final > > > If cli command is used with connect option without given connection parameter the "-c" option will throw an exception and the "--connect" will not connect without any message. > As before the default should be used to connect -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11731) Add blockhound to query module

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11731?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11731: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Add blockhound to query module > ------------------------------ > > Key: ISPN-11731 > URL: https://issues.redhat.com/browse/ISPN-11731 > Project: Infinispan > Issue Type: Enhancement > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > We need to make sure that various parts of the query module do not run blocking code in non blocking threads. We should add blockhound and make sure to fix all violations by running on the blocking thread or appropriately. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11701) Add store migration capabilities to the CLI

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11701?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11701: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Add store migration capabilities to the CLI > ------------------------------------------- > > Key: ISPN-11701 > URL: https://issues.redhat.com/browse/ISPN-11701 > Project: Infinispan > Issue Type: Task > Components: CLI, Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Labels: supportability > Fix For: 12.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11636) Remove node suspected error code from Hot Rod protocol

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11636?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11636: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > 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 > Assignee: Dan Berindei > Priority: Major > Fix For: 12.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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11634) Merge TopologyUpdateStableCommand and TopologyUpdateCommand

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11634?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11634: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > 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: 12.0.0.Final > > > {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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11633) Hotrod Transactional Client can be blocking

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11633?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11633: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Hotrod Transactional Client can be blocking > ------------------------------------------- > > Key: ISPN-11633 > URL: https://issues.redhat.com/browse/ISPN-11633 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > Various methods on the transactional hot rod client will become blocking, despite the API showing as non blocking. This is due to invoking the `getMetadata` method which should use the non blocking variant instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11784) Combine netty and non blocking thread pools

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11784?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11784: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Combine netty and non blocking thread pools > ------------------------------------------- > > Key: ISPN-11784 > URL: https://issues.redhat.com/browse/ISPN-11784 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > We cannot simply drop in our non blocking thread pool as an executor for netty io event loop group. The reason is because Netty takes over control of that thread and only runs tasks submitted to its various event loops. To consolidate these we need to replace our non blocking thread pool with the netty thread pool so it can awake the thread to process tasks. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11759) ProtocolServer should use BlockingManager instead of Executor

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11759?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11759: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > ProtocolServer should use BlockingManager instead of Executor > ------------------------------------------------------------- > > Key: ISPN-11759 > URL: https://issues.redhat.com/browse/ISPN-11759 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > Protocol Servers use an Executor to submit tasks that may block. We should instead use the new BlockingManager as it properly handles the blocking threads. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11797) Introduce strong typed indexing configuration

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11797?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11797: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Introduce strong typed indexing configuration > --------------------------------------------- > > Key: ISPN-11797 > URL: https://issues.redhat.com/browse/ISPN-11797 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Affects Versions: 11.0.0.Dev05 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Final > > > {code:xml} >  > <indexing> > <indexed-entities> > <indexed-entity>org.infinispan.query.test.Person</indexed-entity> > </indexed-entities> > </indexing> > {code} > {code:xml} >  > <indexing storage="file" path="${server.data}/index"> > <indexed-entities> > <indexed-entity>org.infinispan.query.test.Person</indexed-entity> > </indexed-entities> > </indexing> > {code} > {code:xml} > <indexing storage="heap"> > <indexed-entities> > <indexed-entity>org.infinispan.query.test.Person</indexed-entity> > </indexed-entities> > </indexing> > {code} > {code:xml} >  > <indexing storage="file" path="${server.data}/index"> > <index-reader refresh-interval="10s"/> >  > <index-writer mode="async" commit-internal="10s"/> > <indexed-entities> > <indexed-entity>org.infinispan.query.test.Person</indexed-entity> > </indexed-entities> > <properties> > <property name="default.indexwriter.merge_factor">30</property> > </properties> > </indexing> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 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 June 2020