June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBREM-1334) Failure on connection not detected.

by Doug Grove (JIRA)

Doug Grove created JBREM-1334: --------------------------------- Summary: Failure on connection not detected. Key: JBREM-1334 URL: https://issues.jboss.org/browse/JBREM-1334 Project: JBoss Remoting Issue Type: Bug Affects Versions: 2.5.4.SP4 Environment: Red Hat JBoss EAP 5.1.2 Reporter: Doug Grove Lookin at BisocketServerInvoker.run(): {code} if (!t.checkConnection()) { t.shutdown(); synchronized (this) { if (!running) return; controlConnectionThreadMap.remove(listenerId); Object o = controlConnectionRestartsMap.get(listenerId); int restarts = ((Integer)o).intValue(); if (restarts + 1 > controlConnectionRestarts) { log.warn(this + ": detected failure on control connection " + t); log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); log.warn("Assuming it is a connection to an old server, and will not restart"); controlConnectionRestartsMap.remove(listenerId); continue; } log.warn(this + ": detected failure on control connection " + t + " (" + listenerId + ": requesting new control connection"); } {code} It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1606: ---------------------------------------- Component/s: Security Assignee: (was: Brian Stansberry) > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1606: ------------------------------------------ When looking at this we should examine the possibility of actually supporting allow-resource-service-restart=true, as opposed to correcting the metadata. But this all ties in to the elytron migration as well, i.e. we shouldn't change the behavior of security-realm in a way that will be different from what the elytron subsystem stuff supports. > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-1606 at 6/23/16 1:37 PM: ------------------------------------------------------------------- [~iweiss] https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... is wrong. SecurityRealmChildRemoveHandler does not support the allow-resource-service-restart=true header. I believe this is a common mistake in the uses of SecurityRealmParentRestartHandler; the first other one I checked had the same problem. was (Author: brian.stansberry): [~iweiss] https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... is wrong. SecurityRealmChildRemoveHandler does not support the {allow-resource-service-restart=true} header. I believe this is a common mistake in the uses of SecurityRealmParentRestartHandler; the first other one I checked had the same problem. > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1606: ------------------------------------------ [~iweiss] https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... is wrong. SecurityRealmChildRemoveHandler does not support the {allow-resource-service-restart=true} header. I believe this is a common mistake in the uses of SecurityRealmParentRestartHandler; the first other one I checked had the same problem. > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2083) Specifying prefix in S3_PING or GOOGLE_PING causes property validation failures

by Alan Field (JIRA)

Alan Field created JGRP-2083: -------------------------------- Summary: Specifying prefix in S3_PING or GOOGLE_PING causes property validation failures Key: JGRP-2083 URL: https://issues.jboss.org/browse/JGRP-2083 Project: JGroups Issue Type: Bug Affects Versions: 3.6.9 Reporter: Alan Field Assignee: Bela Ban S3_PING.validateProperties() has a check to verify that both location and prefix are not set, but the superclass FILE_PING sets the value for location. In order to use prefix, the location property has to be set to null which is not possible in all cases. See ISPN-5097 for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6680: ----------------------------------------------- Aaron Ogburn <aogburn(a)redhat.com> changed the Status of [bug 1343633|https://bugzilla.redhat.com/show_bug.cgi?id=1343633] from ASSIGNED to POST > :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-6680 > URL: https://issues.jboss.org/browse/WFLY-6680 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch, > Reporter: Kristina Clair > Assignee: Radoslav Husar > Fix For: 10.1.0.Final > > > When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error. > On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error. This is the output from the application host: > {noformat} > [domain@localhost:9999 subsystem=modcluster] pwd > /host=localhost/server=cluster2/subsystem=modcluster > [domain@localhost:9999 subsystem=modcluster] :list-proxies > { > "outcome" => "success", > "result" => [ > "web02:8009", > "web01:8009" > ] > } > [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS014749: Operation handler failed: newValue is null", > "rolled-back" => true > } > [domain@localhost:9999 subsystem=modcluster] :read-proxies-info > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS014749: Operation handler failed: newValue is null", > "rolled-back" => true > } > {noformat} > In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6765) Add generic support to ResourceDescriptor for attribute aliases

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-6765: ---------------------------------- Summary: Add generic support to ResourceDescriptor for attribute aliases Key: WFLY-6765 URL: https://issues.jboss.org/browse/WFLY-6765 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 Renaming an attribute is a common enough use case to warrant generic support in wildfly-clustering-common. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6764) Too much code duplication between AddStepHandler and BoottimeAddStepHandler

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6764?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6764: ------------------------------- Description: As the logic in AddStepHandler grows, it needs to be duplicated by BoottimeAddStepHandler, since BoottimeAddStepHandler extends AbstractBoottimeAddStepHandler. To simplify maintenance of these classes, we should have BoottimeAddStepHandler extend AddStepHandler instead, and reimplement the logic from AbstractBoottimeAddStepHandler. (was: As the logic in AddStepHandler grows, it needs to be duplicated by BoottimeAddStepHandler, since it extends AbstractBoottimeAddStepHandler. To simplify maintenance of these classes, we should have BoottimeAddStepHandler extends AddStepHandler and reimplement the logic from AbstractBoottimeAddStepHandler.) > Too much code duplication between AddStepHandler and BoottimeAddStepHandler > --------------------------------------------------------------------------- > > Key: WFLY-6764 > URL: https://issues.jboss.org/browse/WFLY-6764 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > As the logic in AddStepHandler grows, it needs to be duplicated by BoottimeAddStepHandler, since BoottimeAddStepHandler extends AbstractBoottimeAddStepHandler. To simplify maintenance of these classes, we should have BoottimeAddStepHandler extend AddStepHandler instead, and reimplement the logic from AbstractBoottimeAddStepHandler. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6764) Too much code duplication between AddStepHandler and BoottimeAddStepHandler

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-6764: ---------------------------------- Summary: Too much code duplication between AddStepHandler and BoottimeAddStepHandler Key: WFLY-6764 URL: https://issues.jboss.org/browse/WFLY-6764 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 As the logic in AddStepHandler grows, it needs to be duplicated by BoottimeAddStepHandler, since it extends AbstractBoottimeAddStepHandler. To simplify maintenance of these classes, we should have BoottimeAddStepHandler extends AddStepHandler and reimplement the logic from AbstractBoottimeAddStepHandler. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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 June 2016