March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated REMJMX-94: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1191002 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1191002, https://bugzilla.redhat.com/show_bug.cgi?id=1199319) > 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)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-585) Offline CLI for a Host Controller

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-585: --------------------------------------- Summary: Offline CLI for a Host Controller Key: WFCORE-585 URL: https://issues.jboss.org/browse/WFCORE-585 Project: WildFly Core Issue Type: Feature Request Components: CLI, Domain Management Reporter: Brian Stansberry Fix For: 2.0.0.Alpha1 Direct local administration of a Host Controller running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999. As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool. This JIRA is for administering a Host Controller. A separate JIRA, WFCORE-584 is for equivalent functionality for a standalone server. This will require some rework of the Host Controller / Process Controller relationship, as embedding a PC in the CLI makes no sense. The server-lifecycle control functions of the PC will need to be moved into the same process. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-584) Offline CLI for a standalone server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-584?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-584: ------------------------------------ Description: Direct local administration of a standalone server running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999. As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool. This JIRA is for administering a standalone server. A separate JIRA (WFCORE-585) has been filed for equivalent functionality for a Host Controller. was: Direct local administration of a standalone server running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999. As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool. This JIRA is for administering a standalone server. A separate JIRA will be filed for equivalent functionality for a Host Controller. > Offline CLI for a standalone server > ----------------------------------- > > Key: WFCORE-584 > URL: https://issues.jboss.org/browse/WFCORE-584 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > Direct local administration of a standalone server running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999. > > As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool. > This JIRA is for administering a standalone server. A separate JIRA (WFCORE-585) has been filed for equivalent functionality for a Host Controller. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-584) Offline CLI for a standalone server

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-584: --------------------------------------- Summary: Offline CLI for a standalone server Key: WFCORE-584 URL: https://issues.jboss.org/browse/WFCORE-584 Project: WildFly Core Issue Type: Feature Request Components: CLI, Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.Beta1 Direct local administration of a standalone server running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999. As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool. This JIRA is for administering a standalone server. A separate JIRA will be filed for equivalent functionality for a Host Controller. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-71) Allow messages to have expressions resolved at code generation time

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-71?page=com.atlassian.jira.plugin... ] James Perkins updated LOGTOOL-71: --------------------------------- Fix Version/s: 1.2.2.Final (was: 1.2.1.Final) > Allow messages to have expressions resolved at code generation time > ------------------------------------------------------------------- > > Key: LOGTOOL-71 > URL: https://issues.jboss.org/browse/LOGTOOL-71 > Project: Log Tool > Issue Type: Feature Request > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.2.2.Final > > > Allow messages in the {{@Message}} annotation to allow expressions in the format of: > {code} > ${property.name:default} > {code} > A warning message should be generated if the property name was not found. If not default is found an error should be generated. > The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. There should also be an annotation processing option to allow a path to a properties file. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-24) Better support for Maven logging messages

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-24?page=com.atlassian.jira.plugin... ] James Perkins updated LOGTOOL-24: --------------------------------- Fix Version/s: 1.2.2.Final (was: 1.2.1.Final) > Better support for Maven logging messages > ----------------------------------------- > > Key: LOGTOOL-24 > URL: https://issues.jboss.org/browse/LOGTOOL-24 > Project: Log Tool > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > Priority: Optional > Fix For: 1.2.2.Final > > > Maven only prints error and warning messages. Check for ways to print informational and possibly debug messages. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

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

11 years, 3 months

1
0
0 / 0

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

11 years, 3 months

1
0
0 / 0

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

11 years, 3 months

1
0
0 / 0

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

11 years, 3 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 March 2015