November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5418: ----------------------------------------------- Dmitrii Tikhomirov <dtikhomi(a)redhat.com> changed the Status of [bug 1278370|https://bugzilla.redhat.com/show_bug.cgi?id=1278370] from NEW to ASSIGNED > start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode > --------------------------------------------------------------------------------------------------- > > Key: WFLY-5418 > URL: https://issues.jboss.org/browse/WFLY-5418 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.4.3 > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR4 > > > It is possible to start/stop delivery of messages to MDB in standalone mode using operations > start-delivery() and stop-delivery() on MDB deployment. > Those operations are available in domain mode but their descriptions are missing (preventing CLI autocompletion to work as expected). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-5418: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1278370, https://bugzilla.redhat.com/show_bug.cgi?id=1277460, https://bugzilla.redhat.com/show_bug.cgi?id=1266913 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1266913, https://bugzilla.redhat.com/show_bug.cgi?id=1277460) > start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode > --------------------------------------------------------------------------------------------------- > > Key: WFLY-5418 > URL: https://issues.jboss.org/browse/WFLY-5418 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.4.3 > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR4 > > > It is possible to start/stop delivery of messages to MDB in standalone mode using operations > start-delivery() and stop-delivery() on MDB deployment. > Those operations are available in domain mode but their descriptions are missing (preventing CLI autocompletion to work as expected). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[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 commented on REMJMX-94: ----------------------------------------------- Richard Janík <rjanik(a)redhat.com> changed the Status of [bug 1257031|https://bugzilla.redhat.com/show_bug.cgi?id=1257031] from ON_QA to VERIFIED > 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 > Fix For: 2.0.2.CR1 > > > 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.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-5418: ----------------------------------- WFCORE-1111 is a RFE to expose RUNTIME_ONLY methods on domain servers by JMX > start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode > --------------------------------------------------------------------------------------------------- > > Key: WFLY-5418 > URL: https://issues.jboss.org/browse/WFLY-5418 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.4.3 > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR4 > > > It is possible to start/stop delivery of messages to MDB in standalone mode using operations > start-delivery() and stop-delivery() on MDB deployment. > Those operations are available in domain mode but their descriptions are missing (preventing CLI autocompletion to work as expected). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1111) Expose runtime methods in JMX for resources in domain servers

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFCORE-1111: ----------------------------------- Summary: Expose runtime methods in JMX for resources in domain servers Key: WFCORE-1111 URL: https://issues.jboss.org/browse/WFCORE-1111 Project: WildFly Core Issue Type: Feature Request Components: JMX Affects Versions: 2.0.0.Final Reporter: Jeff Mesnil Assignee: Kabir Khan The JMX subsystem only exposes MBean operations for READ_ONLY management operations on domain servers. It should also be possible to expose RUNTIME_ONLY management operations as they only deal with the runtime and do not alter the management model. WFLY-5418 is an example of such operations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1014) DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1014?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1014: ------------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1266615|https://bugzilla.redhat.com/show_bug.cgi?id=1266615] from ON_QA to VERIFIED > DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1014 > URL: https://issues.jboss.org/browse/WFCORE-1014 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.0.CR6 > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > Fix For: 2.0.0.CR6 > > > The deployment scanner doesn't properly consider the result outcome of its read child operation during getDeploymentsStatus(). This has bad consequences if the operation fails, for instance due to an OOME or possibly some other unexpected exception. > The operation catches the exception and returns an empty result. The deployment scanner misinterprets that empty result to mean there are no applications deployed and sets .undeployed marker files for all of them. The deployment scanner should confirm if the operation was a success or not so we can avoid potential side effects of undeployed applications from an OOME. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5393) Using deprecated attribute use-hornetq-store in CLI does not have any effect being set

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/WFLY-5393?page=com.atlassian.jira.plugin.... ] Amos Feng commented on WFLY-5393: --------------------------------- It looks like the similar setting with "JOURNAL_STORE_ENABLE_ASYNC_IO" and "HORNETQ_STORE_ENABLE_ASYNC_IO" > Using deprecated attribute use-hornetq-store in CLI does not have any effect being set > -------------------------------------------------------------------------------------- > > Key: WFLY-5393 > URL: https://issues.jboss.org/browse/WFLY-5393 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 10.0.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: Amos Feng > Fix For: 10.0.0.Final > > > Attribute {{use-hornetq-store}} was deprecated for EAP7 and {{use-journal-store}} should be used instead. But even the attribute is deprecated it still should provide its old functionality. > I think that using {{use-hornetq-store}} would have the same effect as when {{use-journal-store}} is used. > I would think that when one of the attribute is set then the other one should present the same settings. > {code} > /subsystem=transactions:read-attribute(name=use-hornetq-store) > { > "outcome" => "success", > "result" => false > } > /subsystem=transactions:read-attribute(name=use-journal-store) > { > "outcome" => "success", > "result" => false > } > /subsystem=transactions:write-attribute(name=use-journal-store, value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > :shutdown(restart=true) > {"outcome" => "success"} > /subsystem=transactions:read-attribute(name=use-journal-store) > { > "outcome" => "success", > "result" => true > } > /subsystem=transactions:read-attribute(name=use-hornetq-store) > { > "outcome" => "success", > "result" => false > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5393) Using deprecated attribute use-hornetq-store in CLI does not have any effect being set

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/WFLY-5393?page=com.atlassian.jira.plugin.... ] Amos Feng updated WFLY-5393: ---------------------------- Fix Version/s: 10.0.0.Final > Using deprecated attribute use-hornetq-store in CLI does not have any effect being set > -------------------------------------------------------------------------------------- > > Key: WFLY-5393 > URL: https://issues.jboss.org/browse/WFLY-5393 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 10.0.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: Amos Feng > Fix For: 10.0.0.Final > > > Attribute {{use-hornetq-store}} was deprecated for EAP7 and {{use-journal-store}} should be used instead. But even the attribute is deprecated it still should provide its old functionality. > I think that using {{use-hornetq-store}} would have the same effect as when {{use-journal-store}} is used. > I would think that when one of the attribute is set then the other one should present the same settings. > {code} > /subsystem=transactions:read-attribute(name=use-hornetq-store) > { > "outcome" => "success", > "result" => false > } > /subsystem=transactions:read-attribute(name=use-journal-store) > { > "outcome" => "success", > "result" => false > } > /subsystem=transactions:write-attribute(name=use-journal-store, value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > :shutdown(restart=true) > {"outcome" => "success"} > /subsystem=transactions:read-attribute(name=use-journal-store) > { > "outcome" => "success", > "result" => true > } > /subsystem=transactions:read-attribute(name=use-hornetq-store) > { > "outcome" => "success", > "result" => false > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1033) ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1033?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1033: ------------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from ON_QA to VERIFIED > ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-1033 > URL: https://issues.jboss.org/browse/WFCORE-1033 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 2.0.0.CR7 > > > {noformat} > &amp#27;[0m&amp#27;[31m14:51:47,114 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.NullPointerException > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.jboss.as.network.ManagedMulticastSocketBinding.bind(ManagedMulticastSocketBinding.java:78) > at java.net.MulticastSocket.<init>(MulticastSocket.java:172) > at org.jboss.as.network.ManagedMulticastSocketBinding.<init>(ManagedMulticastSocketBinding.java:54) > at org.jboss.as.network.ManagedMulticastSocketBinding.create(ManagedMulticastSocketBinding.java:40) > at org.jboss.as.network.SocketBindingManagerImpl.createMulticastSocket(SocketBindingManagerImpl.java:82) > at org.jboss.as.clustering.jgroups.ManagedSocketFactoryNew.createMulticastSocket(ManagedSocketFactoryNew.java:127) > at org.jgroups.util.Util.createMulticastSocket(Util.java:3089) > at org.jgroups.protocols.MPING.start(MPING.java:190) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) > at org.jgroups.JChannel.startStack(JChannel.java:890) > at org.jgroups.JChannel._preConnect(JChannel.java:553) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:279) > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94) > {noformat} > This is because the MulticastSocket and DatagramSocket constructors call bind(...), but the ManagedBindingRegistry is not yet set. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5449?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5449: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from ON_QA to VERIFIED > Custom socket factory for JGroups subsystem not set correctly > ------------------------------------------------------------- > > Key: WFLY-5449 > URL: https://issues.jboss.org/browse/WFLY-5449 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR2 > Reporter: Dennis Reed > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 10.0.0.CR4 > > > Wildfly's JChannelFactory tries to set a custom socket factory on the JGroups transport. > This is not the correct API to use, and it gets overwritten when the JGroups channel starts. > A custom socket factory should be set on the JChannel. > The only time the custom socket factory is currently used is if there's a race condition where two channels are started at the same time, and the custom factory is set just before the other channel uses it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 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 November 2015