March 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10044) Upgrade Spring Boot tutorial version

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10044?page=com.atlassian.jira.plugin... ] Work on ISPN-10044 started by Katia Aresti. ------------------------------------------- > Upgrade Spring Boot tutorial version > ------------------------------------ > > Key: ISPN-10044 > URL: https://issues.jboss.org/browse/ISPN-10044 > Project: Infinispan > Issue Type: Enhancement > Components: Demos and Tutorials > Affects Versions: 9.4.9.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > We are now supporting both versions, 2.1.x and 1.5.17. > Starters simple examples should point to 2.1.x since all the community is moving to Spring-Boot 2. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10043) Add explicit dependency on surefire-testng

by Dan Berindei (Jira)

Dan Berindei created ISPN-10043: ----------------------------------- Summary: Add explicit dependency on surefire-testng Key: ISPN-10043 URL: https://issues.jboss.org/browse/ISPN-10043 Project: Infinispan Issue Type: Task Components: Build Affects Versions: 9.4.9.Final, 10.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 10.0.0.Beta3, 9.4.10.Final We need to be able to collect all the dependencies in a private repository and run the build without access to Maven Central for the product. {{maven-surefire-plugin}} doesn't have an explicit dependency on {{surefire-testng}}, instead it resolves it dynamically when it finds {{TestNG}} in the classpath. This means {{surefire-testng}} and its transitive dependencies are not detected automatically and need to be imported manually. When a dependency is not imported, it is pretty hard to debug: there is only a warning during the build: {noformat} [WARNING] Missing POM for org.apache.maven.surefire:surefire-testng-utils:jar:3.0.0-M3 {noformat} And then the failure message only mentions a specific class: {noformat} There was an error in the forked process org/apache/maven/surefire/testng/utils/Stoppable {noformat} We should add an explicit dependency on {{surefire-testng}} on core, like the modules using {{JUnit}} have an explicit dependency on {{surefire-junit47}}, in order to allow automatic detection of its transitive dependencies and to get better error messages. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10043) Add explicit dependency on surefire-testng

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10043?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10043: -------------------------------- Status: Open (was: New) > Add explicit dependency on surefire-testng > ------------------------------------------ > > Key: ISPN-10043 > URL: https://issues.jboss.org/browse/ISPN-10043 > Project: Infinispan > Issue Type: Task > Components: Build > Affects Versions: 10.0.0.Beta2, 9.4.9.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.10.Final > > > We need to be able to collect all the dependencies in a private repository and run the build without access to Maven Central for the product. > {{maven-surefire-plugin}} doesn't have an explicit dependency on {{surefire-testng}}, instead it resolves it dynamically when it finds {{TestNG}} in the classpath. This means {{surefire-testng}} and its transitive dependencies are not detected automatically and need to be imported manually. > When a dependency is not imported, it is pretty hard to debug: there is only a warning during the build: > {noformat} > [WARNING] Missing POM for org.apache.maven.surefire:surefire-testng-utils:jar:3.0.0-M3 > {noformat} > And then the failure message only mentions a specific class: > {noformat} > There was an error in the forked process > org/apache/maven/surefire/testng/utils/Stoppable > {noformat} > We should add an explicit dependency on {{surefire-testng}} on core, like the modules using {{JUnit}} have an explicit dependency on {{surefire-junit47}}, in order to allow automatic detection of its transitive dependencies and to get better error messages. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10037) Create 0.2 Docs for the Infinispan Operator

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10037?page=com.atlassian.jira.plugin... ] Don Naro updated ISPN-10037: ---------------------------- Status: Open (was: New) > Create 0.2 Docs for the Infinispan Operator > ------------------------------------------- > > Key: ISPN-10037 > URL: https://issues.jboss.org/browse/ISPN-10037 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > > Define and develop a set of titles based on customer use cases for the Infinispan operator. Docs should be sourced as modular asciidoc under infinispan-operator/documentation/asciidoc -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10037) Create 0.2 Docs for the Infinispan Operator

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10037?page=com.atlassian.jira.plugin... ] Work on ISPN-10037 started by Don Naro. --------------------------------------- > Create 0.2 Docs for the Infinispan Operator > ------------------------------------------- > > Key: ISPN-10037 > URL: https://issues.jboss.org/browse/ISPN-10037 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > > Define and develop a set of titles based on customer use cases for the Infinispan operator. Docs should be sourced as modular asciidoc under infinispan-operator/documentation/asciidoc -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9990) Integrationtests missing java.se module

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9990?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9990: ------------------------------- Status: Pull Request Sent (was: Reopened) > Integrationtests missing java.se module > --------------------------------------- > > Key: ISPN-9990 > URL: https://issues.jboss.org/browse/ISPN-9990 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 10.0.0.Beta1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.10.Final > > > standalone.sh adds the required {{--add-modules java.se}} to the JVM args for most tests, however if the the container is managed by the test this is not present. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10041) Locking interceptor should check the topology before acquiring locks

by Dan Berindei (Jira)

Dan Berindei created ISPN-10041: ----------------------------------- Summary: Locking interceptor should check the topology before acquiring locks Key: ISPN-10041 URL: https://issues.jboss.org/browse/ISPN-10041 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.4.9.Final, 10.0.0.Beta2, 9.3.6.Final, 8.2.11.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 10.0.0.Beta3 The distribution interceptors check the command topology is the same as the current topology before sending a command to remote nodes, but the locking interceptors do not have any check. On a remote node, this means the inbound invocation handler acquires some locks in topology {{T}}, then the locking interceptor acquires other locks in topology {{T+1}}, and finally the distribution interceptor throws {{OutdatedTopologyException}} and releases the locks. In older versions there is also a potential for blocking a remote executor thread while waiting for the lock, but luckily that is not a problem in 9.4+. It would be more efficient if the locking interceptor was throwing {{OutdatedTopologyException}} instead. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ] Dan Berindei reassigned ISPN-10040: ----------------------------------- Assignee: Dan Berindei > 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.Beta3, 9.4.10.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 month

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10040: -------------------------------- Status: Open (was: New) > 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 > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.10.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 month

1
0
0 / 0

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

by Dan Berindei (Jira)

Dan Berindei created ISPN-10040: ----------------------------------- Summary: 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: 9.4.9.Final, 10.0.0.Beta2, 8.2.11.Final Reporter: Dan Berindei Fix For: 10.0.0.Beta3, 9.4.10.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 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2019