March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13191) Docs: invalid CLI instruction in SSL and mod_cluster section

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13191?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13191: ---------------------------------- Description: [standalone@embedded /] /subsystem=elytron/trust-managers=default-trust-manager:write-attribute(name=certificate-revocation-list) Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [ ("subsystem" => "elytron"), ("trust-managers" => "default-trust-manager") ]" > Docs: invalid CLI instruction in SSL and mod_cluster section > ------------------------------------------------------------ > > Key: WFLY-13191 > URL: https://issues.redhat.com/browse/WFLY-13191 > Project: WildFly > Issue Type: Task > Components: Documentation, mod_cluster > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > [standalone@embedded /] /subsystem=elytron/trust-managers=default-trust-manager:write-attribute(name=certificate-revocation-list) > Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [ > ("subsystem" => "elytron"), > ("trust-managers" => "default-trust-manager") > ]" -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13191) Docs: invalid CLI instruction in SSL and mod_cluster section

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-13191: ------------------------------------- Summary: Docs: invalid CLI instruction in SSL and mod_cluster section Key: WFLY-13191 URL: https://issues.redhat.com/browse/WFLY-13191 Project: WildFly Issue Type: Task Components: Documentation, mod_cluster Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-308) MP Fault Tolerance - unexpected behaviour @Fallback method calls with @Bulkhead

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFWIP-308?page=com.atlassian.jira.plugin... ] Radoslav Husar resolved WFWIP-308. ---------------------------------- Resolution: Done Fixed with WFLY-13190. > MP Fault Tolerance - unexpected behaviour @Fallback method calls with @Bulkhead > ------------------------------------------------------------------------------- > > Key: WFWIP-308 > URL: https://issues.redhat.com/browse/WFWIP-308 > Project: WildFly WIP > Issue Type: Bug > Components: MP Fault Tolerance > Reporter: Ondrej Kotek > Assignee: Radoslav Husar > Priority: Blocker > > MP FT does behave correctly in case when there is {{@Bulkhead}}, {{@Timeout}} and {{@Fallback}} and {{@Asynchronous}} on service method. Some of requests do not go to fallback method but end with {{InterruptedException}}. > Test scenario: > - Deploy MP FT service with: > {noformat} > @Asynchronous > @Bulkhead(value = 15, waitingTaskQueue = 15) > @Timeout(value = 1000) > @Fallback(fallbackMethod = "processFallback") > public CompletionStage<MyConnection> bulkheadTimeout(boolean fail) throws InterruptedException { > if (fail) { > Thread.sleep(2000); > } > return CompletableFuture.completedFuture(new MyConnection() { > @Override > public String getData() { > return "Hello from @Bulkhead @Timeout method"; > } > }); > } > private CompletionStage<MyConnection> processFallback(boolean fail) { > return CompletableFuture.completedFuture(new MyConnection() { > @Override > public String getData() { > return "Fallback Hello"; > } > }); > } > {noformat} > - Send 10+ parallel requests with fail == true > Expected result: > All requests should go to fallback. > Actual Result: > Random number of requests (close to the number of requests) go to fallback. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-307) MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFWIP-307?page=com.atlassian.jira.plugin... ] Radoslav Husar edited comment on WFWIP-307 at 3/4/20 7:46 AM: -------------------------------------------------------------- Fixed with WFLY-13190. was (Author: rhusar): Fixed. > MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker > ------------------------------------------------------------------------------------- > > Key: WFWIP-307 > URL: https://issues.redhat.com/browse/WFWIP-307 > Project: WildFly WIP > Issue Type: Bug > Components: MP Fault Tolerance > Reporter: Miroslav Novak > Assignee: Radoslav Husar > Priority: Blocker > > MP FT does not behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value. > Test scenario: > * Deploy MP FT service with: > {code} > @Asynchronous > @Retry(retryOn = IOException.class) > @CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75) > @Fallback(fallbackMethod = "processFallback") > public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException { > System.out.println("retryCircuitBreaker - called - " + counter); > if (counter % 4 != 0) { // 3/4 requests trigger IOException > System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception"); > throw new IOException("Simulated IOException"); > } > System.out.println("retryCircuitBreaker - called - " + counter + " success"); > return CompletableFuture.completedFuture(new MyConnection() { > @Override > public String getData() { > return "Hello from @Retry @CircuitBreaker method" + counter; > } > }); > } > private CompletionStage<MyConnection> processFallback(int counter) { > System.out.println("processFallback - returned url counter: " + counter); > return CompletableFuture.completedFuture(new MyConnection() { > @Override > public String getData() { > return "Fallback Hello" + counter; > } > }); > } > {code} > * Sends 16 parallel requests. Every 4th requests pass (including 0th one as there is modulo 4), and 12 invocations fail on IOException. > * Try on more request and check that @Fallback method was called as circuit is open > Expected result: > Circuit gets opened and @Fallback method is called. > Actual Result: > Circuit is not opened and @Fallback method is called. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-307) MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFWIP-307?page=com.atlassian.jira.plugin... ] Radoslav Husar resolved WFWIP-307. ---------------------------------- Resolution: Done Fixed. > MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker > ------------------------------------------------------------------------------------- > > Key: WFWIP-307 > URL: https://issues.redhat.com/browse/WFWIP-307 > Project: WildFly WIP > Issue Type: Bug > Components: MP Fault Tolerance > Reporter: Miroslav Novak > Assignee: Radoslav Husar > Priority: Blocker > > MP FT does not behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value. > Test scenario: > * Deploy MP FT service with: > {code} > @Asynchronous > @Retry(retryOn = IOException.class) > @CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75) > @Fallback(fallbackMethod = "processFallback") > public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException { > System.out.println("retryCircuitBreaker - called - " + counter); > if (counter % 4 != 0) { // 3/4 requests trigger IOException > System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception"); > throw new IOException("Simulated IOException"); > } > System.out.println("retryCircuitBreaker - called - " + counter + " success"); > return CompletableFuture.completedFuture(new MyConnection() { > @Override > public String getData() { > return "Hello from @Retry @CircuitBreaker method" + counter; > } > }); > } > private CompletionStage<MyConnection> processFallback(int counter) { > System.out.println("processFallback - returned url counter: " + counter); > return CompletableFuture.completedFuture(new MyConnection() { > @Override > public String getData() { > return "Fallback Hello" + counter; > } > }); > } > {code} > * Sends 16 parallel requests. Every 4th requests pass (including 0th one as there is modulo 4), and 12 invocations fail on IOException. > * Try on more request and check that @Fallback method was called as circuit is open > Expected result: > Circuit gets opened and @Fallback method is called. > Actual Result: > Circuit is not opened and @Fallback method is called. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1525) When SSO is enabled, multipart form and form enconding stop working.

by Mark Banierink (Jira)

[ https://issues.redhat.com/browse/ELY-1525?page=com.atlassian.jira.plugin.... ] Mark Banierink commented on ELY-1525: ------------------------------------- As [~david.guthrie] already stated, the solution is focussed on Keycloak. With default FORM authentication mechanism it still doesn't work. > When SSO is enabled, multipart form and form enconding stop working. > -------------------------------------------------------------------- > > Key: ELY-1525 > URL: https://issues.redhat.com/browse/ELY-1525 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.6.Final, 1.2.1.Final > Reporter: Estevão Góes > Priority: Critical > Attachments: 0001-ELY-1525-Initialize-FormParserFactory-with-FormEncod.patch, ely-1515-reproducer.zip > > > I developed a JSF application with "h:inputFile" component and it requires a form with " enctype="multipart/form-data" ". > I use this tutorial for SSO: https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On . > When I execute the last step: " /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=example-keystore, key-alias=localhost, domain=localhost, credential-reference=clear-text=secret}) ", all commandButtons stop working. > If I remove the "h:inputFile" component and " enctype="multipart/form-data" " from form all buttons works again, but all words with accents are corrupted. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2451) FD_ALL3: improvements over FD_ALL

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/JGRP-2451?page=com.atlassian.jira.plugin... ] Dan Berindei commented on JGRP-2451: ------------------------------------ I propose something like {{FD_ALL2}}, but with {{N=timeout/interval}} bits per member # Every time the timer task runs: ## If all N bits are 0, suspect the member ## Increment the bit index ## Set the current bit to 0 # Every time a message is received: ## Set the current bit to 1 E.g. with timeout=3s and interval=20s, N=3 bits # Start at time T with all bits set # At time T+20s, all bits are set, and the timer sets bit(1) = 0 # At any time between T+20 and T+40, a message arrives, and it sets bit(1) = 1 # At time T+40s, the timer sets bit(2) = 0 # At time T+60s, the timer sets bit(0) = 0 # At time T+80s, the timer sets bit(1) = 0 # At time T+100s, the timer finally sees that all bits are 0 and suspects the node Thus the time between the last heartbeat and the node being suspected is between 60s and 80s. > FD_ALL3: improvements over FD_ALL > --------------------------------- > > Key: JGRP-2451 > URL: https://issues.redhat.com/browse/JGRP-2451 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0, 4.2.1 > > > Improvements to {{FD_ALL}}. > * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed). > * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat > It is crucial that setting the in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time. > The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P. > We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0. > However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2403) Dump information in panic scenarios

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2403?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2403: --------------------------- Description: When there is a panic situation (e.g. thread pool exhausted), dump information (e.g. including a thread dump) to a file at FATAL level. Also dump the most important information to another log (file) periodically (e.g. every 15 minutes). This log should be enabled by default, e.g. in Infinispan. These files can be sent to support via an SOS report. was: When there is a panic situation (e.g. thread pool exhausted), dump information to a file at FATAL level. Also dump the most important information to another log (file) periodically (e.g. every 15 minutes). This log should be enabled by default, e.g. in Infinispan. These files can be sent to support via an SOS report. > Dump information in panic scenarios > ----------------------------------- > > Key: JGRP-2403 > URL: https://issues.redhat.com/browse/JGRP-2403 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0, 4.2.1 > > > When there is a panic situation (e.g. thread pool exhausted), dump information (e.g. including a thread dump) to a file at FATAL level. > Also dump the most important information to another log (file) periodically (e.g. every 15 minutes). This log should be enabled by default, e.g. in Infinispan. > These files can be sent to support via an SOS report. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1081) Automate Sidecar error: https://github.com/kiali/kiali/pull/2468

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1081: ------------------------------------- Summary: Automate Sidecar error: https://github.com/kiali/kiali/pull/2468 Key: SWSQE-1081 URL: https://issues.redhat.com/browse/SWSQE-1081 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13190) Upgrade smallrye-fault-tolerance to 4.1.1

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13190?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13190: ---------------------------------- Description: Brings in a couple of fixes. > Upgrade smallrye-fault-tolerance to 4.1.1 > ----------------------------------------- > > Key: WFLY-13190 > URL: https://issues.redhat.com/browse/WFLY-13190 > Project: WildFly > Issue Type: Task > Components: MP Fault Tolerance > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 19.0.0.Beta3, 20.0.0.Beta1 > > > Brings in a couple of fixes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2020