April 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10113) Cluster description properties should be under `spec` field

by Vittorio Rigamonti (Jira)

Vittorio Rigamonti created ISPN-10113: ----------------------------------------- Summary: Cluster description properties should be under `spec` field Key: ISPN-10113 URL: https://issues.jboss.org/browse/ISPN-10113 Project: Infinispan Issue Type: Feature Request Components: Operator Affects Versions: 0.2.1 Reporter: Vittorio Rigamonti Assignee: Vittorio Rigamonti As specified in [k8s doc|https://github.com/kubernetes/community/blob/master/contributors/deve...] desired status of an object must be under `spec` field. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10112) Docs: CLI Script is ispn-cli.sh for Community

by Donald Naro (Jira)

Donald Naro created ISPN-10112: ---------------------------------- Summary: Docs: CLI Script is ispn-cli.sh for Community Key: ISPN-10112 URL: https://issues.jboss.org/browse/ISPN-10112 Project: Infinispan Issue Type: Enhancement Affects Versions: 10.0.0.Beta4, 9.4.13.Final Reporter: Donald Naro Assignee: Donald Naro Script should be 'cli.sh' for the product, not 'ispn-cli.sh'. Need to update all references in docs. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9852) Invocations waiting for a new topology should resume in parallel

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9852?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9852: ---------------------------------- Fix Version/s: 9.4.13.Final (was: 9.4.12.Final) > Invocations waiting for a new topology should resume in parallel > ---------------------------------------------------------------- > > Key: ISPN-9852 > URL: https://issues.jboss.org/browse/ISPN-9852 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.11.Final, 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.13.Final > > > When a command requires a topology newer than the current topology, it uses {{StateTransferLock.transactionDataFuture()}} to wait for the newer topology. When the tx data is received for the newer topology, some (most?) of the waiting operations do not use a separate executor, instead they are all resumed on the thread that received the tx data. If some operations block (e.g. because of a store), it could take a very long time to finish all the blocked operations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10040) Embedded and server thread pool defaults should be the same

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10040: ----------------------------------- Fix Version/s: 9.4.13.Final (was: 9.4.12.Final) > Embedded and server thread pool defaults should be the same > ----------------------------------------------------------- > > Key: ISPN-10040 > URL: https://issues.jboss.org/browse/ISPN-10040 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 8.2.11.Final, 10.0.0.Beta2, 9.4.9.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.13.Final > > > Embedded: > {code:java} > DEFAULT_THREAD_COUNT.put(REMOTE_COMMAND_EXECUTOR, 200); > DEFAULT_QUEUE_SIZE.put(REMOTE_COMMAND_EXECUTOR, 0); > {code} > Server: > {code:java} > REMOTE_COMMAND("remote-command", 25, 25, 100000, 60000), > {code} > Using a huge queue is not ok for the remote thread pool, but I missed it before because I assumed the server was using the {{KnownComponentNames}} defaults. We should unify the thread pool defaults in another class with a more topical name and remove {{KnownComponentNames}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10062) Docs refer to infinispan-cli-server instead of infinispan-cli-interpreter

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10062?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10062: ----------------------------------- Fix Version/s: 9.4.13.Final (was: 9.4.12.Final) > Docs refer to infinispan-cli-server instead of infinispan-cli-interpreter > ------------------------------------------------------------------------- > > Key: ISPN-10062 > URL: https://issues.jboss.org/browse/ISPN-10062 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Core > Affects Versions: 10.0.0.Beta2, 9.4.10.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.13.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10070) DefaultCacheManager should stop components after start failure

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10070?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10070: ----------------------------------- Fix Version/s: 9.4.13.Final (was: 9.4.12.Final) > DefaultCacheManager should stop components after start failure > -------------------------------------------------------------- > > Key: ISPN-10070 > URL: https://issues.jboss.org/browse/ISPN-10070 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.Beta2, 9.4.10.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.13.Final > > > Currently it is impossible to release all the resources allocated during startup if the {{DefaultCacheManager}} instance was created with {{start=true}}. The user has to do something like this: > {code:java} > DefaultCacheManager manager = new DefaultCacheManager(..., false); > try { > manager.start(); > } catch (Throwable t) { > manager.stop(); > throw t; > } > {code} > Both the constructor and the public {{start()}} method should clean up the started components after a startup failure, so that the user doesn't have to call {{stop()}} explicitly. > Our tests do not currently call {{stop()}} explicitly, so they leak threads and sockets when a manager fails to start (e.g. because something went wrong with the {{CONFIG}} cache). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10080) Test cache managers created in other threads cannot join the UDP cluster

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10080?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10080: ----------------------------------- Fix Version/s: 9.4.13.Final (was: 9.4.12.Final) > Test cache managers created in other threads cannot join the UDP cluster > ------------------------------------------------------------------------ > > Key: ISPN-10080 > URL: https://issues.jboss.org/browse/ISPN-10080 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 10.0.0.Beta3, 9.4.11.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.13.Final > > > When a test wants to create a cache manager in another thread (e.g. with {{fork()}}) it should be able to call {{TestResourceTracker.testThreadStarted(this)}} and join the same cluster. > That works with TCP, but with UDP each thread gets its own multicast address and port, so multicast messages from one node don't reach the other. Unicast messages and {{TEST_PING}} do work. > This is the issue that made {{FunctionalTxTest}} fail in https://github.com/infinispan/infinispan/pull/6442 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10074) DefaultSegmentedDataContainer executeTask() and iterator() include expired entries

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10074?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10074: ----------------------------------- Fix Version/s: 9.4.13.Final (was: 9.4.12.Final) > DefaultSegmentedDataContainer executeTask() and iterator() include expired entries > ---------------------------------------------------------------------------------- > > Key: ISPN-10074 > URL: https://issues.jboss.org/browse/ISPN-10074 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.Beta2, 9.4.10.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Beta4, 9.4.13.Final > > > The {{executeTask()}} javadoc doesn't mention expired entries, but {{iterator()}}'s says they shouldn't be included, and non-segmented containers do not include them. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10086) AllClusterExecutorTest.testExecutorTriConsumerTimeoutException random failures

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10086?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10086: ----------------------------------- Fix Version/s: 9.4.13.Final (was: 9.4.12.Final) > AllClusterExecutorTest.testExecutorTriConsumerTimeoutException random failures > ------------------------------------------------------------------------------ > > Key: ISPN-10086 > URL: https://issues.jboss.org/browse/ISPN-10086 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 10.0.0.Beta3, 9.4.11.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Beta4, 9.4.13.Final > > > When running tests in parallel, the remote request may complete before the thread that sent the request resumes. Because the scheduled executor is mocked to return {{null}}, this leads to a {{NullPointerException}}: > {noformat} > 09:43:41,995 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.manager.AllClusterExecutorTest.testExecutorTriConsumerTimeoutException > java.lang.NullPointerException: null > at org.infinispan.remoting.transport.AbstractRequest.setTimeoutFuture(AbstractRequest.java:94) ~[classes/:?] > at org.infinispan.remoting.transport.AbstractRequest.setTimeout(AbstractRequest.java:55) ~[classes/:?] > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeCommand(JGroupsTransport.java:831) ~[classes/:?] > at org.infinispan.manager.impl.AllClusterExecutor.submitConsumer(AllClusterExecutor.java:182) ~[classes/:?] > at org.infinispan.manager.ClusterExecutor.submitConsumer(ClusterExecutor.java:116) ~[classes/:?] > at org.infinispan.manager.Test$17.call(AllClusterExecutorTest.java:402) ~[test-classes/:?] > at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1601) ~[test-classes/:?] > at org.infinispan.manager.AllClusterExecutorTest.testExecutorTriConsumerTimeoutException(AllClusterExecutorTest.java:382) ~[test-classes/:?] > {noformat} > The problem may be that the test calls {{Mockito.verify()}} from the consumer twice, once for each node, instead of doing it only on the remote node. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10095) Shared stores should throw exception when cache is local

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10095?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10095: ----------------------------------- Fix Version/s: 9.4.13.Final (was: 9.4.12.Final) > Shared stores should throw exception when cache is local > -------------------------------------------------------- > > Key: ISPN-10095 > URL: https://issues.jboss.org/browse/ISPN-10095 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 10.0.0.Beta3, 9.4.11.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.13.Final > > > A shared store does not make sense with a local cache, therefore we should throw a {{CacheConfigurationException}} if configured. Due to assumptions elsewhere in the PersistenceManager, prior to this fix a NPE will be thrown during the Purge method of the store as {{transport == null}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2019