August 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10539) Server Logging management via REST

by Gustavo Fernandes (Jira)

Gustavo Fernandes created ISPN-10539: ---------------------------------------- Summary: Server Logging management via REST Key: ISPN-10539 URL: https://issues.jboss.org/browse/ISPN-10539 Project: Infinispan Issue Type: Feature Request Components: REST Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes For inspecting, altering the logging configuration by looking at the installed LogMaanger -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10535) ServerNG Docs: /master/server/runtime/README.md > asciidoc

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10535?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10535: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7249 > ServerNG Docs: /master/server/runtime/README.md > asciidoc > ---------------------------------------------------------- > > Key: ISPN-10535 > URL: https://issues.jboss.org/browse/ISPN-10535 > Project: Infinispan > Issue Type: Enhancement > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Productize reference information in the server readme. Needs to be sourced in asciidoc. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10535) ServerNG Docs: /master/server/runtime/README.md > asciidoc

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10535?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10535: ------------------------------- Status: Open (was: New) > ServerNG Docs: /master/server/runtime/README.md > asciidoc > ---------------------------------------------------------- > > Key: ISPN-10535 > URL: https://issues.jboss.org/browse/ISPN-10535 > Project: Infinispan > Issue Type: Enhancement > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Productize reference information in the server readme. Needs to be sourced in asciidoc. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10486) REST endpoint documentation missing the /rest/ context

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10486?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10486: ------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > REST endpoint documentation missing the /rest/ context > ------------------------------------------------------ > > Key: ISPN-10486 > URL: https://issues.jboss.org/browse/ISPN-10486 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Donald Naro > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10435) Support for serving the console

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10435?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10435: ------------------------------------- Description: The REST endpoint should be able to serve the console from a static folder, respecting usual http headers sent by browsers to facilitate caching such as if-modified-since (was: The REST endpoint should be able to serve the console from a static folder) > Support for serving the console > ------------------------------- > > Key: ISPN-10435 > URL: https://issues.jboss.org/browse/ISPN-10435 > Project: Infinispan > Issue Type: Feature Request > Components: REST > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: console-ng > > The REST endpoint should be able to serve the console from a static folder, respecting usual http headers sent by browsers to facilitate caching such as if-modified-since -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10435) Support for serving the console

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10435?page=com.atlassian.jira.plugin... ] Work on ISPN-10435 started by Gustavo Fernandes. ------------------------------------------------ > Support for serving the console > ------------------------------- > > Key: ISPN-10435 > URL: https://issues.jboss.org/browse/ISPN-10435 > Project: Infinispan > Issue Type: Feature Request > Components: REST > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: console-ng > > The REST endpoint should be able to serve the console from a static folder -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10435) Support for serving the console

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10435?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10435: ------------------------------------- Status: Open (was: New) > Support for serving the console > ------------------------------- > > Key: ISPN-10435 > URL: https://issues.jboss.org/browse/ISPN-10435 > Project: Infinispan > Issue Type: Feature Request > Components: REST > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: console-ng > > The REST endpoint should be able to serve the console from a static folder -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9425) HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-9425?page=com.atlassian.jira.plugin.... ] Work on ISPN-9425 started by Pedro Ruivo. ----------------------------------------- > HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-9425 > URL: https://issues.jboss.org/browse/ISPN-9425 > Project: Infinispan > Issue Type: Bug > Reporter: Diego Lovison > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 10.0.0.Final > > > There are 3 scenarios and I believe that they are correlated. If it is not the case, a JIRA for each item should be open. > All scenarios below are multiple clients and one server. The following steps should be executed does not matter what is the scenario. > * Add one breakpoint at the first line of the method `acceptResponse` at the class PrepareTransactionOperation > * Add one breakpoint at the first line of the method `executeOperation` at the class PrepareTransactionOperation > *Scenario 1* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume. It will stop at `executeOperation`. > * Wait 5 minutes or any time greater than 60 seconds ( I was not able to identify the right period of time but greater than 60 seconds should work), Resume and Resume the "Program 2". It will fail. > * The issue in scenario 1 is: Why doesn't matter the amount of time since it is greater than 60 seconds the request will fail? I am expecting something like a timeout in the "Program 1" and not expire when a call in that key was called for the first time. > * Kill all clients and servers > *Scenario 2* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume. > * Program 1 -> Resume. > * The issue in scenario 2 is: Why the test fails due: expected value 'null' different from 'random-value-generated' > * Kill all clients and servers > *Scenario 3* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume. > * Wait 60 seconds > * Re-run Program 2 -> Resume, Resume, Resume, Resume. It will work. > * Program 1 -> Resume, it will fail due to an assertion error > * The issue in scenario 3 is: When resuming the "Program 1" I am expecting an error during the commit phase and not an assertion error. > * Kill all clients and servers > Program 1 means that you should run the client code. It will create a separated JVM. > Program 2 means that you should run the client code. It will create a separated JVM. > It will be nice if we find out an way to automate this kind of tests. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9425) HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-9425?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-9425: ------------------------------ Status: Open (was: New) > HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-9425 > URL: https://issues.jboss.org/browse/ISPN-9425 > Project: Infinispan > Issue Type: Bug > Reporter: Diego Lovison > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 10.0.0.Final > > > There are 3 scenarios and I believe that they are correlated. If it is not the case, a JIRA for each item should be open. > All scenarios below are multiple clients and one server. The following steps should be executed does not matter what is the scenario. > * Add one breakpoint at the first line of the method `acceptResponse` at the class PrepareTransactionOperation > * Add one breakpoint at the first line of the method `executeOperation` at the class PrepareTransactionOperation > *Scenario 1* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume. It will stop at `executeOperation`. > * Wait 5 minutes or any time greater than 60 seconds ( I was not able to identify the right period of time but greater than 60 seconds should work), Resume and Resume the "Program 2". It will fail. > * The issue in scenario 1 is: Why doesn't matter the amount of time since it is greater than 60 seconds the request will fail? I am expecting something like a timeout in the "Program 1" and not expire when a call in that key was called for the first time. > * Kill all clients and servers > *Scenario 2* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume. > * Program 1 -> Resume. > * The issue in scenario 2 is: Why the test fails due: expected value 'null' different from 'random-value-generated' > * Kill all clients and servers > *Scenario 3* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume. > * Wait 60 seconds > * Re-run Program 2 -> Resume, Resume, Resume, Resume. It will work. > * Program 1 -> Resume, it will fail due to an assertion error > * The issue in scenario 3 is: When resuming the "Program 1" I am expecting an error during the commit phase and not an assertion error. > * Kill all clients and servers > Program 1 means that you should run the client code. It will create a separated JVM. > Program 2 means that you should run the client code. It will create a separated JVM. > It will be nice if we find out an way to automate this kind of tests. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9425) HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-9425?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-9425: ------------------------------ Fix Version/s: 10.0.0.Final > HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-9425 > URL: https://issues.jboss.org/browse/ISPN-9425 > Project: Infinispan > Issue Type: Bug > Reporter: Diego Lovison > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 10.0.0.Final > > > There are 3 scenarios and I believe that they are correlated. If it is not the case, a JIRA for each item should be open. > All scenarios below are multiple clients and one server. The following steps should be executed does not matter what is the scenario. > * Add one breakpoint at the first line of the method `acceptResponse` at the class PrepareTransactionOperation > * Add one breakpoint at the first line of the method `executeOperation` at the class PrepareTransactionOperation > *Scenario 1* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume. It will stop at `executeOperation`. > * Wait 5 minutes or any time greater than 60 seconds ( I was not able to identify the right period of time but greater than 60 seconds should work), Resume and Resume the "Program 2". It will fail. > * The issue in scenario 1 is: Why doesn't matter the amount of time since it is greater than 60 seconds the request will fail? I am expecting something like a timeout in the "Program 1" and not expire when a call in that key was called for the first time. > * Kill all clients and servers > *Scenario 2* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume. > * Program 1 -> Resume. > * The issue in scenario 2 is: Why the test fails due: expected value 'null' different from 'random-value-generated' > * Kill all clients and servers > *Scenario 3* > * Execute the client code ( Program 1 ) > * Execute the client code ( Program 2 ) > * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. > * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume. > * Wait 60 seconds > * Re-run Program 2 -> Resume, Resume, Resume, Resume. It will work. > * Program 1 -> Resume, it will fail due to an assertion error > * The issue in scenario 3 is: When resuming the "Program 1" I am expecting an error during the commit phase and not an assertion error. > * Kill all clients and servers > Program 1 means that you should run the client code. It will create a separated JVM. > Program 2 means that you should run the client code. It will create a separated JVM. > It will be nice if we find out an way to automate this kind of tests. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 7 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 August 2019