[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?
by Georgy Go (JIRA)
[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ]
Georgy Go edited comment on WFLY-4373 at 3/6/15 10:44 AM:
----------------------------------------------------------
No, because .close() in 80% of cases won't allow the program to run further.
And there's no exceptions
was (Author: wilddev):
No, because .close() in 80% of cases won't allow program to run further.
And there's not exceptions
> WildFly CLI API ModelControllerClient memory leak?
> --------------------------------------------------
>
> Key: WFLY-4373
> URL: https://issues.jboss.org/browse/WFLY-4373
> Project: WildFly
> Issue Type: Bug
> Components: CLI, IO
> Affects Versions: 8.2.0.Final
> Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final
> Reporter: Georgy Go
> Assignee: Alexey Loubyansky
> Labels: cli, dmr
>
> The following snippet of code to redeploy an application:
> ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999);
> ModelNode operation = new ModelNode();
> operation.get("operation").set("redeploy");
> operation.get("address").add("deployment", "server.war");
> cl.execute(operation);
> cl.close();
> - works fine, but .close() freezes forever.
> This issue depends to not only redeploy, but also for any other operations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?
by Georgy Go (JIRA)
[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ]
Georgy Go edited comment on WFLY-4373 at 3/6/15 10:44 AM:
----------------------------------------------------------
No, because .close() in 80% of cases won't allow program to run further.
And there's not exceptions
was (Author: wilddev):
No, because .close() in 80% of cases won't allow program to run further.
> WildFly CLI API ModelControllerClient memory leak?
> --------------------------------------------------
>
> Key: WFLY-4373
> URL: https://issues.jboss.org/browse/WFLY-4373
> Project: WildFly
> Issue Type: Bug
> Components: CLI, IO
> Affects Versions: 8.2.0.Final
> Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final
> Reporter: Georgy Go
> Assignee: Alexey Loubyansky
> Labels: cli, dmr
>
> The following snippet of code to redeploy an application:
> ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999);
> ModelNode operation = new ModelNode();
> operation.get("operation").set("redeploy");
> operation.get("address").add("deployment", "server.war");
> cl.execute(operation);
> cl.close();
> - works fine, but .close() freezes forever.
> This issue depends to not only redeploy, but also for any other operations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?
by Georgy Go (JIRA)
[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ]
Georgy Go commented on WFLY-4373:
---------------------------------
No, because .close() in 80% of cases won't allow program to run further.
> WildFly CLI API ModelControllerClient memory leak?
> --------------------------------------------------
>
> Key: WFLY-4373
> URL: https://issues.jboss.org/browse/WFLY-4373
> Project: WildFly
> Issue Type: Bug
> Components: CLI, IO
> Affects Versions: 8.2.0.Final
> Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final
> Reporter: Georgy Go
> Assignee: Alexey Loubyansky
> Labels: cli, dmr
>
> The following snippet of code to redeploy an application:
> ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999);
> ModelNode operation = new ModelNode();
> operation.get("operation").set("redeploy");
> operation.get("address").add("deployment", "server.war");
> cl.execute(operation);
> cl.close();
> - works fine, but .close() freezes forever.
> This issue depends to not only redeploy, but also for any other operations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4373:
-----------------------------------
Is it related to REM3-200 ?
> WildFly CLI API ModelControllerClient memory leak?
> --------------------------------------------------
>
> Key: WFLY-4373
> URL: https://issues.jboss.org/browse/WFLY-4373
> Project: WildFly
> Issue Type: Bug
> Components: CLI, IO
> Affects Versions: 8.2.0.Final
> Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final
> Reporter: Georgy Go
> Assignee: Alexey Loubyansky
> Labels: cli, dmr
>
> The following snippet of code to redeploy an application:
> ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999);
> ModelNode operation = new ModelNode();
> operation.get("operation").set("redeploy");
> operation.get("address").add("deployment", "server.war");
> cl.execute(operation);
> cl.close();
> - works fine, but .close() freezes forever.
> This issue depends to not only redeploy, but also for any other operations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on REMJMX-94:
----------------------------------------
Brad, WFCORE-553 sounds different from the description of this JIRA. The description describes what sounds like a classloader leak in the client. WFCORE-553 is a server side problem with inefficient cleanup of server thread pools, such that the number of file descriptors used by the server is excessive if the pace of opening and closing remoting management channels outpaces the gc. It's more a problem that a load test fixture like your reproducer for https://bugzilla.redhat.com/show_bug.cgi?id=1193926 would hit.
> Memory leak in remoting-jmx
> ---------------------------
>
> Key: REMJMX-94
> URL: https://issues.jboss.org/browse/REMJMX-94
> Project: Remoting JMX
> Issue Type: Bug
> Affects Versions: 1.1.3.Final
> Reporter: Libor Zoubek
> Assignee: Darran Lofthouse
> Labels: memory_leak
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org...
> I am not sure if memleak is in remoting-jmx or some other underlying stuff.
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-583:
---------------------------------------
Summary: Think about interactive slave domain controller registration.
Key: WFCORE-583
URL: https://issues.jboss.org/browse/WFCORE-583
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave.
As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible.
- Start slave domain controller disconnected.
- Start CLI and connect to slave using local auth.
- Execute join-domain(hostname, port)
At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store.
Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master.
The slave process generates a public and private key and with interaction with the administrator a certificate signing request.
The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave.
The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead.
Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs.
This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation.
Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ELY-164) A KeyStore wrapper to track if modifications are made.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-164:
------------------------------------
Summary: A KeyStore wrapper to track if modifications are made.
Key: ELY-164
URL: https://issues.jboss.org/browse/ELY-164
Project: WildFly Elytron
Issue Type: Feature Request
Components: SSL
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Alpha1
Unlike the UnmodifiableKeyStore this time need to track if methods are called that succeed and make modifications.
This will be used by the subsystem to provide an indication to the user that the in-memory instance may not be in sync with the persisted instance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?
by Georgy Go (JIRA)
[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ]
Georgy Go updated WFLY-4373:
----------------------------
Priority: Major (was: Blocker)
> WildFly CLI API ModelControllerClient memory leak?
> --------------------------------------------------
>
> Key: WFLY-4373
> URL: https://issues.jboss.org/browse/WFLY-4373
> Project: WildFly
> Issue Type: Bug
> Components: CLI, IO
> Affects Versions: 8.2.0.Final
> Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final
> Reporter: Georgy Go
> Assignee: Alexey Loubyansky
> Labels: cli, dmr
>
> The following snippet of code to redeploy an application:
> ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999);
> ModelNode operation = new ModelNode();
> operation.get("operation").set("redeploy");
> operation.get("address").add("deployment", "server.war");
> cl.execute(operation);
> cl.close();
> - works fine, but .close() freezes forever.
> This issue depends to not only redeploy, but also for any other operations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months