December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-385) Allow for configuration of respawn policy in host.xml/domain.xml

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-385?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-712 to WFCORE-385: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-385 (was: WFLY-712) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Allow for configuration of respawn policy in host.xml/domain.xml > ---------------------------------------------------------------- > > Key: WFCORE-385 > URL: https://issues.jboss.org/browse/WFCORE-385 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Beta1 > > > The server manager currently uses the default respawn policy -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-386) Ability to configure a custom RBAC implementation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-386?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2002 to WFCORE-386: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-386 (was: WFLY-2002) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Ability to configure a custom RBAC implementation > ------------------------------------------------- > > Key: WFCORE-386 > URL: https://issues.jboss.org/browse/WFCORE-386 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Priority: Optional > Labels: RBAC-WF-only > Fix For: 1.0.0.Beta1 > > > Allow configuration of a module name and set of key/value properties to allow users to plug in a custom implementation of the CustomAuthorizer interface. The impl would be loadable via the ServiceLoader mechanism. > The hooks to integrate such a custom impl into the server are already done, so this is should be just a matter of adding the config capability. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-387) Describe inheritance relationships in the resource description metadata

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-387?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-546 to WFCORE-387: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-387 (was: WFLY-546) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Describe inheritance relationships in the resource description metadata > ----------------------------------------------------------------------- > > Key: WFCORE-387 > URL: https://issues.jboss.org/browse/WFCORE-387 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > Some elements in the management model have an inheritance relationship with other elements located elsewhere. For example, system properties can be defined as a child of the root domain resource, as a child of a server-group resource, as a child of the root host resource, and as a child of the server-config resource. > The resource description metadata for a resource needs to describe these relationships. It needs to cover the inheritance hierarchy, as well as how any conflicts are resolved (i.e. does the child win, as is the case with system properties and interfaces, or is some sort of merging strategy employed, as is the case with profiles and socket-binding-groups, where the sets of child resources (subsystems and socket-bindings) are merged, provided that the two sets are disjoint. > A factor to include in this metadata is whether the relationship is fixed (i.e. host system-property inherits from server-group) or whether there is some attribute that defines the inheritance (e.g. a profile's that "includes" another profile has an attribute that defines the name of the included profile.) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-380) Operations to read content from the content repository

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-380?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-554 to WFCORE-380: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-380 (was: WFLY-554) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > Operations to read content from the content repository > ------------------------------------------------------ > > Key: WFCORE-380 > URL: https://issues.jboss.org/browse/WFCORE-380 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > Fix For: 1.0.0.Beta1 > > > Ability to pull data out of the content repository. We can do that with rollout plans, but not for deployments or if we add deployment content overlays. > Basically, if the user loses the original of the deployment, let's let them get it back via the management API and remove the temptation for them to hack into the repository. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-381) xinclude support in the management model

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-381?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-324 to WFCORE-381: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-381 (was: WFLY-324) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > xinclude support in the management model > ---------------------------------------- > > Key: WFCORE-381 > URL: https://issues.jboss.org/browse/WFCORE-381 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Jason Greene > Fix For: 1.0.0.Beta1 > > > Ability to use xinclude in the domain/xml/host.xml/standalone.xml documents. Not necessarily anywhere, but where the model supports storing the information. Upon changes to the model, persistence of the relevant elements would be to the specified file. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-369) HostControllerConnectionService connection timeout is not configurable

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-369?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-231 to WFCORE-369: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-369 (was: WFLY-231) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > HostControllerConnectionService connection timeout is not configurable > ---------------------------------------------------------------------- > > Key: WFCORE-369 > URL: https://issues.jboss.org/browse/WFCORE-369 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Dominik Pospisil > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Beta1 > > > I am seeing intermittent failures when starting AS7 in domain mode. It seems that this is due to HostControllerConnectionService has hardcoded 15s timeout when trying to connect to DC. I think that this value should be configurable. > HostControllerConnectionService.java: > ... > ProtocolChannelClient.Configuration configuration = new ProtocolChannelClient.Configuration(); > configuration.setEndpoint(endpointInjector.getValue()); > configuration.setConnectionTimeout(15000); > configuration.setUri(new URI("remote://" + hcAddressInjector.getValue().getHostName() + ":" + hcAddressInjector.getValue().getPort())); > client = ProtocolChannelClient.create(configuration); > ... > Exception I am getting: > [Server:server-two] 13:52:54,766 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.host.controller.channel: org.jboss.msc.service.StartException in service jboss.host.controller.channel: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out > [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:103) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] > [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] > [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] > [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22] > [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22] > [Server:server-two] at java.lang.Thread.run(Thread.java:679) [:1.6.0_22] > [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out > [Server:server-two] at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:166) [jboss-as-protocol-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[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)

11 years, 7 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)

11 years, 7 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)

11 years, 7 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)

11 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

2008

2007

2006

jboss-jira December 2014