December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-370) Improve RBAC Performance

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-370?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2147 to WFCORE-370: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-370 (was: WFLY-2147) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Improve RBAC Performance > ------------------------ > > Key: WFCORE-370 > URL: https://issues.jboss.org/browse/WFCORE-370 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > Parent task for work related to reducing the impact of RBAC (WFLY-490) on management operation performance. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-371) Expose mgmt client socket binding config through ModelControllerClient Factory

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-371?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-229 to WFCORE-371: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-371 (was: WFLY-229) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Expose mgmt client socket binding config through ModelControllerClient Factory > ------------------------------------------------------------------------------ > > Key: WFCORE-371 > URL: https://issues.jboss.org/browse/WFCORE-371 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > Parent task used a secret system property to configure this to support Open Shift's immediate need, but proper configuration is needed. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-377) The management API should provide a command to restart only all servers that are in state 'reload-required'

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-538 to WFCORE-377: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-377 (was: WFLY-538) Affects Version/s: (was: 8.0.0.Alpha1) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > The management API should provide a command to restart only all servers that are in state 'reload-required' > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-377 > URL: https://issues.jboss.org/browse/WFCORE-377 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Wolf-Dieter Fink > Assignee: Emanuel Muckenhuber > Labels: cli, domain, management > Fix For: 1.0.0.Beta1 > > > After configuration changes via CLI batch it might be that different processes needs to be restarted. > It is possible to iterate over all servers and check it. > But I think it would be easier to have a command that restart all controllers and servers conditional to the 'relod required' state > - at domain level > - at host level > - at server level > command example : > :restart(ifRequired=true) > :reload(ifRequired=true) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-378) Domain rollout operation timeouts

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-378?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2742 to WFCORE-378: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-378 (was: WFLY-2742) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Domain rollout operation timeouts > --------------------------------- > > Key: WFCORE-378 > URL: https://issues.jboss.org/browse/WFCORE-378 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > Portion of the parent task related to rolling out changes to a domain. > The expectation is that single process timeouts (WFLY-2741) will handle most failure conditions related to domain rollouts (e.g. if a single server hangs, preventing completion of the rollout, eventually that server will time out, allowing the domain wide rollout to continue.) Timeouts in the domain rollout code serve as a second line of defense: > 1) In case of protocol or other problems that prevent the calling process learning about the timeout on the remote process > 2) In case of bugs in the single process timeout handling on the remote process > 3) In mixed domain cases where remote hosts are running previous versions and do not have the timeout function > Potential places to add timeouts: > DomainSlaveHandler->HostControllerUpdateTask.ProxyOperationListener.retrievePreparedOperation() > -- where the master HC waits for responses from slaves > RollingServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation() > -- timeout here means 1 server didn't respond, but need to move on to next > ConcurrentServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation() > -- timeout here means none of the remaining servers have responded w/in the timeout > DomainRolloutStepHandler.finalizeOp() -> future.get() > ---- the ServerGroupUpdateTask should fail in the normal phase, so any timeout here would indicate a problem committing the tx or a comms problem getting back the response -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-379) Give option to make the content repository browsable

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-379?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-549 to WFCORE-379: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-379 (was: WFLY-549) Affects Version/s: (was: 8.0.0.Alpha1) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Give option to make the content repository browsable > ---------------------------------------------------- > > Key: WFCORE-379 > URL: https://issues.jboss.org/browse/WFCORE-379 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ben Schofield > Fix For: 1.0.0.Beta1 > > > JBoss admins regularly need to view the application content that is deployed to a server. On previous versions of JBoss this was easy to do with the deploy directory. When using the new API to install applications the contents of applications are not easily browsable or searchable. > Would like to have a setting that enables all content to be stored in exploded format in the content repository. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-365) inconsistent usage of min/max-occurs in model description

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-365?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-142 to WFCORE-365: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-365 (was: WFLY-142) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > inconsistent usage of min/max-occurs in model description > --------------------------------------------------------- > > Key: WFCORE-365 > URL: https://issues.jboss.org/browse/WFCORE-365 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Enrique González Martínez > Fix For: 1.0.0.Beta1 > > Attachments: patch.txt > > > The usages of min/max-occurs in the model description are not consistent - e.g. missing in ResourceDescription, mostly wrong when used in the descriptionProvider or outdated examples in the documentation. > I'll attach a simple patch which should actually fix that issue in line with the documentation [1] (incl. recursive usage) and the usage of the CLI (ls -l). However there might be more to it. > [1] https://docs.jboss.org/author/display/AS71/Description+of+the+Management+... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-366) Support timeout of management operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-366?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2740 to WFCORE-366: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-366 (was: WFLY-2740) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Support timeout of management operations > ---------------------------------------- > > Key: WFCORE-366 > URL: https://issues.jboss.org/browse/WFCORE-366 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > There have been various situations where bugs in WF or in user code have prevented management operations from completing, leaving the ModelController locked permanently, unless the process is stopped. There should be mechanism via which timeouts can be set. > My proposal is to allow a timeout to be set via a management operation header. In addition, there will be a standard timeout that will apply if no header is present. > The standard timeout will be quite lengthy, probably several minutes. The goal is to allow a management process to eventually auto-recover, not to do prompt detection of failures. Users can use the header if they wish prompt detection a failures. A short standard timeout runs the risk of false positives, particularly with large deployments. > The meaning of this timeout is not to be an overall maximum time for operation execution. There would be no valid default for such a timeout in a managed domain, where the time it would take to roll out a change would depend on the size of the domain and the rollout plan. > Rather, this timeout is meant to be the maximum period operation execution threads can block in various points. Blocking for longer than the timeout would result in operation failure. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-368) Ability for processes to be placed in a state rejecting config changes and requiring a restart

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-368?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2882 to WFCORE-368: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-368 (was: WFLY-2882) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Ability for processes to be placed in a state rejecting config changes and requiring a restart > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-368 > URL: https://issues.jboss.org/browse/WFCORE-368 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > If a condition occurs whereby a managed process is in an unknown and inconsistent state, we need the ability to mark the process as being unsafe to modify in terms of configuration and requiring restart. > Examples of this kind of situation in a standalone server would include: > 1) timeouts waiting for MSC stability as envisioned in WFLY-2741. > 2) failures that occur in operation rollback. > In these cases, it is no longer practical to determine how internal service state relates to configuration state. Allowing further configuration changes will exacerbate the situation. The process should be restarted in order to restore consistency before allowing further config changes. > In a domain environment this can also include servers that are inconsistent with respect to the domain model because some update has failed on that server but the rollout plan allowed the update to commit on other servers. > In this case, the server config is inconsistent with the domain and subsequent changes to the domain will not make it consistent, so they should not be propagated to the server. The server needs to be restarted in order to get a complete configuration. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-367) Move ClientConfigurationImpl factory methods into ModelControllerClientConfiguration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-367?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-209 to WFCORE-367: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-367 (was: WFLY-209) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Move ClientConfigurationImpl factory methods into ModelControllerClientConfiguration > ------------------------------------------------------------------------------------ > > Key: WFCORE-367 > URL: https://issues.jboss.org/browse/WFCORE-367 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > Fix For: 1.0.0.Beta1 > > > ClientConfigurationImpl includes a bunch of static factory methods that would fit better in a Factory class in the ModelControllerClientConfiguration interface. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-361) CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-361?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-533 to WFCORE-361: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-361 (was: WFLY-533) Affects Version/s: (was: 8.0.0.Alpha1) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error) > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-361 > URL: https://issues.jboss.org/browse/WFCORE-361 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Pavel Janousek > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > The same situation is with every shipped and supported configuration/profile. As base for my explanation I'm using standalone.xml. Standalone.xml declares xmlns as: > {code} > <server xmlns="urn:jboss:domain:1.3"> > {code} > The real XSD file which defined elements is jboss-eap-6.0/docs/schema/jboss-as-config_1_3.xsd. > The very common Linux system has implemented and enabled dualstack in these days. If we instruct AS instance to bind to +any+ IPv4 address via {code}<interface name="public"> > <any-ipv4-address /> > </interface>{code} > The real result is to bind running AS instance to +any+ IP address, not only in IPv4 address space but in IPv6 too! > With default setting (= -Djava.net.preferIPv4Stack=true), result is correct - it is bound to ANY IPv4 addresses only. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014