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

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-749) Events deserialization is broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-749?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-749: ------------------------------------------------ Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1205666|https://bugzilla.redhat.com/show_bug.cgi?id=1205666] from MODIFIED to ON_QA > Events deserialization is broken > -------------------------------- > > Key: DROOLS-749 > URL: https://issues.jboss.org/browse/DROOLS-749 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.3.0.Beta1 > > > When a KieSession is deserialized the events present in the old serialized session are reasserted into the new session. Then if one of this event causes a scheduler to be immediately triggered this is done in a callback out of the main evaluation loop. This implies that the left tuples resulting from the triggering of the scheduler aren't propagated to the sink of the TimerNode which created the scheduler itself. This missing propagation can, in some circumstances, cause a NullPointerException like the following: > {code} > java.lang.NullPointerException > at org.drools.core.phreak.PhreakTimerNode.doLeftDeletes(PhreakTimerNode.java:197) > at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:63) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:364) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:163) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:118) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:254) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:108) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1022) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1352) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1318) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1301) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1280) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4490) Hard deployment using wildfly-maven-plugin

by Hitesh Saxena (JIRA)

[ https://issues.jboss.org/browse/WFLY-4490?page=com.atlassian.jira.plugin.... ] Hitesh Saxena updated WFLY-4490: -------------------------------- Fix Version/s: (was: No Release) > Hard deployment using wildfly-maven-plugin > ------------------------------------------ > > Key: WFLY-4490 > URL: https://issues.jboss.org/browse/WFLY-4490 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 8.2.0.Final > Environment: OS- WIndows7 64Bit, Eclipse Luna Service Release 1(4.4.1), Maven 3.1.1 > Reporter: Hitesh Saxena > Assignee: Paul Gier > Priority: Critical > Labels: jboss > > We are migrating from JBOSS6 to Wildfly8. We are a new issue which could not be found anywhere in forums,so posting this question here. > > For hard deployment we were using the below configuration in pom.xml which actually copy and deploy ear file from ${JBOSS_HOME}/server/default/deploy directory of JBOSS6. > > <plugin> > <groupId>org.codehaus.mojo</groupId> > <artifactId>jboss-maven-plugin</artifactId> > <executions> > <execution> > <id>deploy_ear</id> > <phase>pre-integration-test</phase> > <goals> > <goal>hard-deploy</goal> > </goals> > <configuration> > <deploySubDir>./</deploySubDir> > <fileName>target/${project.build.finalName.full}</fileName> > <unpack>true</unpack> > </configuration> > </execution> > </executions> > </plugin> > > But now as per wildlfy documents, we are using wildfly-maven-plugin to do the above and configured as below: > > <plugin> > <groupId>org.wildfly.plugins</groupId> > <artifactId>wildfly-maven-plugin</artifactId> > <executions> > <execution> > <id>deploy_ear</id> > <phase>package</phase> > <goals> > <goal>deploy</goal> > </goals> > <configuration> > <skip>false</skip> > <filename>test.ear</filename> > <targetDir>${project_directory}\target</targetDir> > <domain>standalone</domain> > </configuration> > </execution> > </executions> > </plugin> > > But this maven configuration deploys into ${JBOSS_HOME}/standalone/data/content and also make an entry into standalone-full-ha.xml file as below > <deployments> > <deployment name="test.ear" runtime-name="test.ear"> > <content sha1="697809d5ebb7658fd7045dd6a8c41542cd3a0e02"/> > </deployment> > </deployments> > > Ideally it should copy and deploy from into ${JBOSS_HOME}/standalone/deployments folder. > > I tried to see the parameters from wildfly documents but could not get any parameter which can do the expected. > reference: WildFly Maven Plugin - wildfly:deploy > > Help will be highly appreciated as we are struck into this stage. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4490) Hard deployment using wildfly-maven-plugin

by Hitesh Saxena (JIRA)

Hitesh Saxena created WFLY-4490: ----------------------------------- Summary: Hard deployment using wildfly-maven-plugin Key: WFLY-4490 URL: https://issues.jboss.org/browse/WFLY-4490 Project: WildFly Issue Type: Bug Components: Build System Affects Versions: 8.2.0.Final Environment: OS- WIndows7 64Bit, Eclipse Luna Service Release 1(4.4.1), Maven 3.1.1 Reporter: Hitesh Saxena Assignee: Paul Gier Priority: Critical Fix For: No Release We are migrating from JBOSS6 to Wildfly8. We are a new issue which could not be found anywhere in forums,so posting this question here. For hard deployment we were using the below configuration in pom.xml which actually copy and deploy ear file from ${JBOSS_HOME}/server/default/deploy directory of JBOSS6. <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jboss-maven-plugin</artifactId> <executions> <execution> <id>deploy_ear</id> <phase>pre-integration-test</phase> <goals> <goal>hard-deploy</goal> </goals> <configuration> <deploySubDir>./</deploySubDir> <fileName>target/${project.build.finalName.full}</fileName> <unpack>true</unpack> </configuration> </execution> </executions> </plugin> But now as per wildlfy documents, we are using wildfly-maven-plugin to do the above and configured as below: <plugin> <groupId>org.wildfly.plugins</groupId> <artifactId>wildfly-maven-plugin</artifactId> <executions> <execution> <id>deploy_ear</id> <phase>package</phase> <goals> <goal>deploy</goal> </goals> <configuration> <skip>false</skip> <filename>test.ear</filename> <targetDir>${project_directory}\target</targetDir> <domain>standalone</domain> </configuration> </execution> </executions> </plugin> But this maven configuration deploys into ${JBOSS_HOME}/standalone/data/content and also make an entry into standalone-full-ha.xml file as below <deployments> <deployment name="test.ear" runtime-name="test.ear"> <content sha1="697809d5ebb7658fd7045dd6a8c41542cd3a0e02"/> </deployment> </deployments> Ideally it should copy and deploy from into ${JBOSS_HOME}/standalone/deployments folder. I tried to see the parameters from wildfly documents but could not get any parameter which can do the expected. reference: WildFly Maven Plugin - wildfly:deploy Help will be highly appreciated as we are struck into this stage. Thanks. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWEB-310) Allow servlets to be marked overridable via Servlet registration API

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-310?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-310: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1196513|https://bugzilla.redhat.com/show_bug.cgi?id=1196513] from ASSIGNED to POST > Allow servlets to be marked overridable via Servlet registration API > -------------------------------------------------------------------- > > Key: JBWEB-310 > URL: https://issues.jboss.org/browse/JBWEB-310 > Project: JBoss Web > Issue Type: Enhancement > Affects Versions: JBossWeb-7.5.0.GA > Reporter: James Livingston > Assignee: Remy Maucherat > Attachments: JBWEB-310.patch > > > To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, JBossWeb needs to add an 'overridable' flag on Wrapper, and not treat new mappings as conflicting if the one previously using the mapping was marked overridable. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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 April 2015