April 2015 - jboss-jira - Jboss List Archives

[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 4/8/15 7:11 AM: --------------------------------------------------------- No, there're 2 deployments at the single WF instance: Kernel.war and asdasd.war. I redeploying asdasd from servlet of another one. was (Author: wilddev): No, there're 2 deployments at the single WF instance: Kernel.war and asdasd.war. I redeploying asdasd from another one. > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, 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: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > 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, 9 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, there're 2 deployments at the single WF instance: Kernel.war and asdasd.war. I redeploying asdasd from another one. > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, 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: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4489) NPE on missing name of <distributed-workmanager>

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-4489?page=com.atlassian.jira.plugin.... ] Jesper Pedersen reassigned WFLY-4489: ------------------------------------- Fix Version/s: 9.0.0.CR1 Assignee: Philippe Marschall (was: Jesper Pedersen) Affects Version/s: 9.0.0.Beta2 > NPE on missing name of <distributed-workmanager> > ------------------------------------------------ > > Key: WFLY-4489 > URL: https://issues.jboss.org/browse/WFLY-4489 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 9.0.0.Beta2 > Reporter: Philippe Marschall > Assignee: Philippe Marschall > Fix For: 9.0.0.CR1 > > > When the name attribute of {{<distributed-workmanager>}} is missing instead of a descriptive log message you get a {{NullPointerException}}. The issue is that the {{StringBuilder}} constructor is called with the value of the name attribute instead of the name of the name attribute ("name"). > Something like this: > {code} > <subsystem xmlns="urn:jboss:domain:jca:2.0"> > <distributed-workmanager/> > </subsystem> > {code} > Will produce a stack trace like this: > {code} > [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > at org.jboss.as.server.ServerService.boot(ServerService.java:347) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at java.lang.StringBuilder.<init>(StringBuilder.java:112) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.parseDistributedWorkManager(JcaExtension.java:560) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:367) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:119) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) > at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1199) > at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:457) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) > {code} > After the patch the stack trace looks like this: > {code} > org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.server.ServerService.boot(ServerService.java:347) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[274,13] > Message: WFLYCTL0133: Missing required attribute(s): name > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.parseDistributedWorkManager(JcaExtension.java:563) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:368) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:120) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1199) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:457) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 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: ----------------------------------- Am I reading thread dump correctly? you call redeploy in servlet from inside application that you want to redeploy? > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, 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: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > 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, 9 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: --------------------------------- Yes it still happen, the threaddump is attached to the issue now (i tested this in webapp, so the only server dump there). I've called this snippet in test app for 3 times: two times it was succeed, last one got frozen. Seems to be I setted the title to <memory leak> up mistakenly. In this way I would to hightlight the threat of not closed session's overlay. XNIO libraries are standart one, it's from maven repository, as suggested to use by WildFly documentation. Worth to note, priority of the bug could take lower because the client can be opened once per app's lifetime, and it's incorrect closing can be handled by GarbageCollector. > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, 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: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-590) SSL secured communication between master and slave in domain mode test case

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-590?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-590: ------------------------------------------------ Ondrej Kotek <okotek(a)redhat.com> changed the Status of [bug 1197058|https://bugzilla.redhat.com/show_bug.cgi?id=1197058] from ASSIGNED to POST > SSL secured communication between master and slave in domain mode test case > --------------------------------------------------------------------------- > > Key: WFCORE-590 > URL: https://issues.jboss.org/browse/WFCORE-590 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 1.0.0.Alpha19 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 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 updated WFLY-4373: ---------------------------- Attachment: threaddump.zip > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, 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: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1258) Remove driver cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1258?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated JBJCA-1258: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1157649 > Remove driver cache > ------------------- > > Key: JBJCA-1258 > URL: https://issues.jboss.org/browse/JBJCA-1258 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Reporter: Jesper Pedersen > Assignee: Lin Gao > Fix For: 1.2.4.Final > > > And interaction with DriverManager -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-99) Release Remoting JMX 2.0.1.CR2

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-99?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved REMJMX-99. ------------------------------------ Resolution: Done > Release Remoting JMX 2.0.1.CR2 > ------------------------------ > > Key: REMJMX-99 > URL: https://issues.jboss.org/browse/REMJMX-99 > Project: Remoting JMX > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-750) Cannot resolve custom accumulate functions after declaring metadata for an existing type

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-750?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-750: ------------------------------------------------ Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1205961|https://bugzilla.redhat.com/show_bug.cgi?id=1205961] from MODIFIED to ON_QA > Cannot resolve custom accumulate functions after declaring metadata for an existing type > ---------------------------------------------------------------------------------------- > > Key: DROOLS-750 > URL: https://issues.jboss.org/browse/DROOLS-750 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.3.0.Beta1 > > > Importing a custom accumulate function and a pojo from a different package the DRL compilation fails with the following message: "Error: Unknown accumulate function: 'myfunc' on rule 'test'. All accumulate functions must be registered before building a resource" -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015