[JBoss JIRA] (WFCORE-920) Add a management subsystem
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-920:
---------------------------------------
Summary: Add a management subsystem
Key: WFCORE-920
URL: https://issues.jboss.org/browse/WFCORE-920
Project: WildFly Core
Issue Type: Component Upgrade
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 3.0.0.Alpha1
As subsystems can also be defined in a host controller we can now move the management configuration into a subsystem, legacy resources however such as security realms can be omitted.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-736) Memory leak in server management controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-736?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-736:
-----------------------------------------
[~pkremens] I suspect on JBEAP-283 you are now seeing WFLY-4881, which is a different issue.
> Memory leak in server management controller
> -------------------------------------------
>
> Key: WFCORE-736
> URL: https://issues.jboss.org/browse/WFCORE-736
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Reporter: Sergey Lisovoy
> Assignee: David Lloyd
> Labels: memory_leak, memoryleak, remoting
> Fix For: 2.0.0.Beta5
>
> Attachments: screenshot-1.png
>
>
> I have a simple thread that monitor remote wildfly process status. After some time client fails. Wildfly server also eat all memory and reports about connection errors. Some times wildfly also fails with fails with OutOfMemory exception.
> Client code:
> {code:java}
> package ru.kamis.tests.xniomemoryleaks;
> import org.jboss.as.controller.client.ModelControllerClient;
> import org.jboss.as.controller.client.helpers.Operations;
> import org.jboss.dmr.ModelNode;
> public class OutOfMemoryDemo {
> public static void main(String[] args) throws Exception {
>
> for(int i=0; i<1000000; i++) {
> ModelControllerClient client = null;
> client = ModelControllerClient.Factory.create("localhost", 9990);
>
> ModelNode operation = Operations.createReadAttributeOperation(new ModelNode().setEmptyList(), "server-state");
> client.execute(operation);
>
> client.close();
>
> if(i % 1000 == 0) {
> System.out.println("Processed: " + i);
> }
> }
> }
> }
> {code}
> Client output:
> {noformat}
> июн 05, 2015 11:21:51 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.0.Final
> июн 05, 2015 11:21:51 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.0.Final
> июн 05, 2015 11:21:51 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.6.Final
> Processed: 0
> Processed: 1000
> Processed: 2000
> Processed: 3000
> Processed: 4000
> Processed: 5000
> Exception in thread "main" java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at ru.kamis.tests.xniomemoryleaks.OutOfMemoryDemo.main(OutOfMemoryDemo.java:12)
> Caused by: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:148)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 2 more
> {noformat}
> Client libraries:
> {code:xml}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-controller-client</artifactId>
> <version>8.2.0.Final</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.remoting</groupId>
> <artifactId>jboss-remoting</artifactId>
> <version>4.0.6.Final</version>
> </dependency>
> {code}
> Project to reproduce error:
> [https://github.com/lis0x90/jboss-remoting-momory-leak-reproduce]
> Wildfly logs:
> {noformat}
> ...
> 2015-06-05 11:21:10,195 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djboss.remoting.leakdebugging=true -Duser.country=RU -Duser.language=en -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=H:\java\wildfly-8.2.0.Final\standalone\log\server.log -Dlogging.configuration=file:H:\java\wildfly-8.2.0.Final\standalone\configuration/logging.properties
> ...
> 2015-06-05 11:21:11,923 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 2259ms - Started 194 of 246 services (86 services are lazy, passive or on-demand)
> 2015-06-05 11:22:51,726 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-2) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:23:59,306 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:24:02,527 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:24:16,142 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-2) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:24:21,312 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:24:27,458 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-2) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-310) Don't copy the contents to all hosts when assigning a deployment to a server-group
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-310?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-310:
----------------------------------
After some discussion:
- Keep command line the same
- Add new options to host.xml (and tell [~dlofthouse]). The command line mappings to attributes should be:
--backup: if ignore-unused-configuration="true" and --backup is provided, then backup-dc="false"
this persists XML for future runs with --cached-dc etc. This should continue to get and save the configs
--cached-dc: maps to cached-dc="true" in host.xml
New host.xml attributes:
- backup-dc: boolean: Try implies all configs and deployments are available in case promotion to DC is performed.
- cached-dc: boolean: If DC is not available on startup, but configurations are available (currently from a previous run with --backup) then the server may still start.
> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-310
> URL: https://issues.jboss.org/browse/WFCORE-310
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: Ken Wills
> Fix For: 2.0.0.CR1
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-301:
-----------------------------------------
https://developer.jboss.org/docs/DOC-52631
> Configuration of individual contexts for http management interface.
> -------------------------------------------------------------------
>
> Key: WFCORE-301
> URL: https://issues.jboss.org/browse/WFCORE-301
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha1
>
>
> At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console.
> The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context.
> We need to start to open up the handling of cross origin requests for a couple of reasons: -
> - Enabling Keycloak SSO support.
> - Alternative console distribution options
> The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default.
> A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-890) Make http-upgrade a child element - also use a complex attribute to hold config.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-890?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-890:
------------------------------------
Parent: WFCORE-299
Issue Type: Sub-task (was: Task)
> Make http-upgrade a child element - also use a complex attribute to hold config.
> --------------------------------------------------------------------------------
>
> Key: WFCORE-890
> URL: https://issues.jboss.org/browse/WFCORE-890
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha1
>
>
> With the switch to Elytron there is a true distinction between referencing authentication configuration for HTTP and authentication configuration for SASL - for this reason if the HTTP management interface will need to reference the SASL configuration independently from the HTTP configuration.
> Some top lovel attributes on the http management interface can also be deprecated as the Elytron configuration already covers these e.g. server-name sasl-protocol.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-890) Make http-upgrade a child element - also use a complex attribute to hold config.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-890?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-890:
------------------------------------
Parent: (was: WFCORE-673)
Issue Type: Task (was: Sub-task)
> Make http-upgrade a child element - also use a complex attribute to hold config.
> --------------------------------------------------------------------------------
>
> Key: WFCORE-890
> URL: https://issues.jboss.org/browse/WFCORE-890
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha1
>
>
> With the switch to Elytron there is a true distinction between referencing authentication configuration for HTTP and authentication configuration for SASL - for this reason if the HTTP management interface will need to reference the SASL configuration independently from the HTTP configuration.
> Some top lovel attributes on the http management interface can also be deprecated as the Elytron configuration already covers these e.g. server-name sasl-protocol.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-919) Allow read-only data/content storage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-919?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFCORE-919 at 8/26/15 11:43 AM:
-------------------------------------------------------------------
The content repository is an internal detail, not an end user API. So this is a proposal to change that. Particularly the "deployments are managed via another system (docker, puppet etc)" bit, would be such a big change as to really require a separate issue altogether.
Without going to that point, but just sharing the repo, some kind of config setting that lets the user independently specify the location of the content repo would be needed. That itself somewhat exposes the internal detail (i.e. that the content repo is implemented via a FS location.) Any config for this would need to be done in such a way that it can become an alternative to some other approach (e.g. someday we pull content via the internet from Mars.)
If the step of making the repo sharable is worked out, then the "read-only" flag for a given host becomes a small thing.
I don't see a *direct* relationship to WFCORE-310, although it does touch on the same general use cases. The tangential relationship is a host that can be master cannot be configured with a r-o repo, as the master is the one who writes. Being configured with a r-o repo would be an issue with promoting a slave to master (as the config would have to be corrected) but the mechanics of promoting a slave are not the direct concern of 310. 310 deals with the fact that a slave that is ignoring parts of the domain-wide config/content is ineligible for promotion.
was (Author: brian.stansberry):
The content repository is an internal detail, not an end user API. So this is a proposal to change that. Particularly the "deployments are managed via another system (docker, puppet etc)" bit, would be such a big change as to really require a separate issue altogether
Without going to that point, but just sharing the repo, some kind of config setting that lets the user independently specify the location of the content repo would be needed. That itself somewhat exposes the internal detail (i.e. that the content repo is implemented via a FS location.) Any config for this would need to be done in such a way that it can become an alternative to some other approach (e.g. someday we pull content via the internet from Mars.)
If the step of making the repo sharable is worked out, then the "read-only" flag for a given host becomes a small thing.
I don't see a *direct* relationship to WFCORE-310, although it does touch on the same general use cases. The tangential relationship is a host that can is master cannot be configured with a r-o repo, as the master is the one who writes. Being configured with a r-o repo would be an issue with promoting a slave to master (as the config would have to be corrected) but the mechanics of promoting a slave are not the direct concern of 310. 310 deals with the fact that a slave that is ignoring parts of the domain-wide config/content is ineligible for promotion.
> Allow read-only data/content storage
> ------------------------------------
>
> Key: WFCORE-919
> URL: https://issues.jboss.org/browse/WFCORE-919
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: James Livingston
> Assignee: Brian Stansberry
>
> It would be nice to allow the content repository to be read-only, if there was an external guarantee that all content should be there. This would be useful in situations where all HCs (including the DC) share that over NFS, or deployments are managed via another system (docker, puppet etc).
> It could be a ContentRepository implementation which does not make chances, and fails if attempted or content is missing. On read-only HCs the current writeability check would need to be disabled, along with the cleaner task, and the DC (if it could write) would need to ensure content was not removed prior to HCs performing undeployment.
> This would presumably have some interaction with WFCORE-310.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months