March 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10087) Add single-stage Dockerfile for operator

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-10087?page=com.atlassian.jira.plugin... ] Galder Zamarreño reassigned ISPN-10087: --------------------------------------- Assignee: Galder Zamarreño (was: Vittorio Rigamonti) > Add single-stage Dockerfile for operator > ---------------------------------------- > > Key: ISPN-10087 > URL: https://issues.jboss.org/browse/ISPN-10087 > Project: Infinispan > Issue Type: Task > Components: Operator > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > > Operator Dockerfile is multi-stage to allow Docker Hub to build and push tags and changes to master. We should keep a separate Dockerfile that's only single-stage for users that have a Docker file that doesn't support multi-stage. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10087) Add single-stage Dockerfile for operator

by Galder Zamarreño (Jira)

Galder Zamarreño created ISPN-10087: --------------------------------------- Summary: Add single-stage Dockerfile for operator Key: ISPN-10087 URL: https://issues.jboss.org/browse/ISPN-10087 Project: Infinispan Issue Type: Task Components: Operator Reporter: Galder Zamarreño Assignee: Vittorio Rigamonti Operator Dockerfile is multi-stage to allow Docker Hub to build and push tags and changes to master. We should keep a separate Dockerfile that's only single-stage for users that have a Docker file that doesn't support multi-stage. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10029) Transactional invalidation cache with shared store prone to stale reads, even with FORCE_WRITE_LOCK

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/ISPN-10029?page=com.atlassian.jira.plugin... ] Paul Ferraro updated ISPN-10029: -------------------------------- Affects Version/s: 9.4.11.Final (was: 9.4.8.Final) > Transactional invalidation cache with shared store prone to stale reads, even with FORCE_WRITE_LOCK > --------------------------------------------------------------------------------------------------- > > Key: ISPN-10029 > URL: https://issues.jboss.org/browse/ISPN-10029 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.6.Final, 9.4.11.Final > Reporter: Paul Ferraro > Priority: Critical > Attachments: InvalidationLockingTest.java > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

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

by Dan Berindei (Jira)

Dan Berindei created ISPN-10086: ----------------------------------- Summary: 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: 9.4.11.Final, 10.0.0.Beta3 Reporter: Dan Berindei Fix For: 10.0.0.Beta4, 9.4.12.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)

5 years, 9 months

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10070?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10070: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6806, https://github.com/infinispan/infinispan/pull/6807 (was: https://github.com/infinispan/infinispan/pull/6807) > 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.12.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)

5 years, 9 months

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10070?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10070: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6807 > 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.12.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)

5 years, 9 months

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10070?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10070: -------------------------------- Status: Open (was: New) > 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.12.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)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10015) Web Site Updates for New Doc Titles

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10015?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10015: ------------------------------- Status: Open (was: New) > Web Site Updates for New Doc Titles > ----------------------------------- > > Key: ISPN-10015 > URL: https://issues.jboss.org/browse/ISPN-10015 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core, Website > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10015) Web Site Updates for New Doc Titles

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10015?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10015: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan.github.io/pull/72 > Web Site Updates for New Doc Titles > ----------------------------------- > > Key: ISPN-10015 > URL: https://issues.jboss.org/browse/ISPN-10015 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core, Website > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10036) Setting Up Infinispan Operator Docs

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10036?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10036: ------------------------------- Sprint: (was: JDG Sprint #26) > Setting Up Infinispan Operator Docs > ----------------------------------- > > Key: ISPN-10036 > URL: https://issues.jboss.org/browse/ISPN-10036 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core, Website > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > # Set up docs under `infinispan-operator/documentation/asciidoc` > # Update infinispan.github.io scripts to build Operator docs on infinispan.org. > Result should be that documentation for the Infinispan Operator is built and correctly formatted on infinispan.org. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2019