[JBoss JIRA] (DROOLS-91) Property reactivity masks are wrong for of inherited properties
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-91?page=com.atlassian.jira.plugin.... ]
Mario Fusco resolved DROOLS-91.
-------------------------------
Fix Version/s: 5.6
6.0.0.Alpha1
Resolution: Done
Fixed by preserving inheritance blocks when calculating the property reactivity masks, i.e. the properties belonging to classes higher in the hierarchy come first in the list of sorted properties.
> Property reactivity masks are wrong for of inherited properties
> ---------------------------------------------------------------
>
> Key: DROOLS-91
> URL: https://issues.jboss.org/browse/DROOLS-91
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 5.6, 6.0.0.Alpha1
>
>
> Lexicographic ordering of settable properties used to sort the properties of an object in a fixed way doesn't work well with inheritance. In fact, since the modification mask is computed based on the pattern type, not the actual object type, the masks intersection can return a wrong result because the 2 masks are calculated on different classes (one extending the other).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6802) acceptor and poller threads not destroyed when reloading
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/AS7-6802?page=com.atlassian.jira.plugin.s... ]
Remy Maucherat commented on AS7-6802:
-------------------------------------
Ok, even if you keep all the service instances around (like, here, WebConnectorService), I don't know why it causes problems since its start method creates a new connector instance (and stop drops it).
> acceptor and poller threads not destroyed when reloading
> --------------------------------------------------------
>
> Key: AS7-6802
> URL: https://issues.jboss.org/browse/AS7-6802
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Fedora 18
> java version "1.7.0_13"
> Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
> Reporter: Alexey Loubyansky
> Assignee: Remy Maucherat
> Attachments: server_thread_dump.txt
>
>
> I'm testing the reload operation. At some point the server becomes unresponsive. One of the reasons is
> 14:39:17,452 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 8.0.0.Alpha1-SNAPSHOT "TBD" started in 240ms - Started 144 of 181 services (55 services are lazy, passive or on-demand)
> 14:39:17,452 ERROR [stderr] (Controller Boot Thread) Controller Boot Thread releasing lock on 565478949
> 14:39:17,713 ERROR [org.xnio.listener] (Remoting "fedorka:MANAGEMENT" read-1) A channel event listener threw an exception: java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method) [rt.jar:1.7.0_13]
> at java.lang.Thread.start(Thread.java:691) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360) [rt.jar:1.7.0_13]
> at org.xnio.XnioWorker.execute(XnioWorker.java:724) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:218) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:518)
> And if look at the thread dump of the server process, I see lots of acceptor and poller threads. See the attached thread dump.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (DROOLS-91) Property reactivity masks are wrong for of inherited properties
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-91:
---------------------------------
Summary: Property reactivity masks are wrong for of inherited properties
Key: DROOLS-91
URL: https://issues.jboss.org/browse/DROOLS-91
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
Lexicographic ordering of settable properties used to sort the properties of an object in a fixed way doesn't work well with inheritance. In fact, since the modification mask is computed based on the pattern type, not the actual object type, the masks intersection can return a wrong result because the 2 masks are calculated on different classes (one extending the other).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6803) NicInterfaceCriteriaUnitTestCase testBasic fails on a host configured with a dual IP stack
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-6803?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka reassigned AS7-6803:
---------------------------------
Assignee: Pavel Janousek (was: Ondrej Zizka)
> NicInterfaceCriteriaUnitTestCase testBasic fails on a host configured with a dual IP stack
> ------------------------------------------------------------------------------------------
>
> Key: AS7-6803
> URL: https://issues.jboss.org/browse/AS7-6803
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Michael Musgrove
> Assignee: Pavel Janousek
>
> This test fails when we run the test suite with the following IPv6 options:
> {noformat}
> -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -Djboss.bind.address=[::1] -Djboss.bind.address.management=[::1] -Djboss.bind.address.unsecure=[::1]
> {noformat}
>
> It appears that the test is expecting an array containing one nic address but instead gets two (IPv4 and IPv6) addresses. The linked JBTM jira is where we initially reported the issue. Test output is:
> {noformat}
> Failed tests:
> testBasic(org.jboss.as.controller.interfaces.NicInterfaceCriteriaUnitTestCase): expected:<[/0:0:0:0:0:0:0:1%1]> but was:<[/0:0:0:0:0:0:0:1%1, /127.0.0.1]>
> testMultipleCriteria(org.jboss.as.controller.interfaces.NotInterfaceCriteriaUnitTestCase): expected:<{name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2]}> but was:<{name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2, /172.17.131.3]}>
> testMultipleCriteria(org.jboss.as.controller.interfaces.AnyInterfaceCriteriaUnitTestCase): expected:<{name:lo (lo)=[/0:0:0:0:0:0:0:1%1], name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2]}> but was:<{name:lo (lo)=[/127.0.0.1, /0:0:0:0:0:0:0:1%1], name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2, /172.17.131.3]}>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (JASSIST-183) API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has changed signature
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-183?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-183.
-----------------------------------
Fix Version/s: 3.18.0-GA
Resolution: Done
I recreated findSuperMethod(Object self, String name, String desc).
> API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has changed signature
> ---------------------------------------------------------------------------------------
>
> Key: JASSIST-183
> URL: https://issues.jboss.org/browse/JASSIST-183
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA, 3.17.1-GA
> Environment: Seam 2.2.2 / 2.3.0, Java 7u9
> Reporter: Andrei Ivanov
> Assignee: Shigeru Chiba
> Priority: Blocker
> Labels: regression
> Fix For: 3.18.0-GA
>
>
> Checking how some applications run with Java 7, I've tried to upgrade to the newly released Javassist just to notice Seam is no longer working:
> {noformat}
> java.lang.NoSuchMethodError: javassist.util.proxy.RuntimeSupport.findSuperMethod(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/reflect/Method;
> at OrderInitializer_$$_javassist_seam_0.writeReplace(OrderInitializer_$$_javassist_seam_0.java)
> at org.jboss.seam.Component.postConstructJavaBean(Component.java:1461)
> at org.jboss.seam.Component.postConstruct(Component.java:1379)
> at org.jboss.seam.Component.newInstance(Component.java:2155)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
> at org.jboss.seam.contexts.ServletLifecycle.endInitialization(ServletLifecycle.java:143)
> at org.jboss.seam.init.Initialization.init(Initialization.java:744)
> at org.jboss.seam.mock.AbstractSeamTest.startSeam(AbstractSeamTest.java:929)
> at org.jboss.seam.mock.SeamTest.startSeam(SeamTest.java:69)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6802) acceptor and poller threads not destroyed when reloading
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/AS7-6802?page=com.atlassian.jira.plugin.s... ]
Alexey Loubyansky commented on AS7-6802:
----------------------------------------
It looks like the issue affects not only the Web but the jacorb-based component.
"AOMRemoval" daemon prio=10 tid=0x00007f44c4268800 nid=0x44c7 waiting on condition [0x00007f446b4b5000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000fca5d7b0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.jacorb.poa.AOM$1.run(AOM.java:120)
At the thread dump I'm looking now, which is not the one attached, there are 255 AOMRemoval threads and a bit less but still more than 200 Web threads.
> acceptor and poller threads not destroyed when reloading
> --------------------------------------------------------
>
> Key: AS7-6802
> URL: https://issues.jboss.org/browse/AS7-6802
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Fedora 18
> java version "1.7.0_13"
> Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
> Reporter: Alexey Loubyansky
> Assignee: Remy Maucherat
> Attachments: server_thread_dump.txt
>
>
> I'm testing the reload operation. At some point the server becomes unresponsive. One of the reasons is
> 14:39:17,452 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 8.0.0.Alpha1-SNAPSHOT "TBD" started in 240ms - Started 144 of 181 services (55 services are lazy, passive or on-demand)
> 14:39:17,452 ERROR [stderr] (Controller Boot Thread) Controller Boot Thread releasing lock on 565478949
> 14:39:17,713 ERROR [org.xnio.listener] (Remoting "fedorka:MANAGEMENT" read-1) A channel event listener threw an exception: java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method) [rt.jar:1.7.0_13]
> at java.lang.Thread.start(Thread.java:691) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360) [rt.jar:1.7.0_13]
> at org.xnio.XnioWorker.execute(XnioWorker.java:724) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:218) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:518)
> And if look at the thread dump of the server process, I see lots of acceptor and poller threads. See the attached thread dump.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6802) acceptor and poller threads not destroyed when reloading
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/AS7-6802?page=com.atlassian.jira.plugin.s... ]
Jean-Frederic Clere commented on AS7-6802:
------------------------------------------
it reloads the whole AS. That is the command :reload when using bin/jboss-cli.sh
> acceptor and poller threads not destroyed when reloading
> --------------------------------------------------------
>
> Key: AS7-6802
> URL: https://issues.jboss.org/browse/AS7-6802
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Fedora 18
> java version "1.7.0_13"
> Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
> Reporter: Alexey Loubyansky
> Assignee: Remy Maucherat
> Attachments: server_thread_dump.txt
>
>
> I'm testing the reload operation. At some point the server becomes unresponsive. One of the reasons is
> 14:39:17,452 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 8.0.0.Alpha1-SNAPSHOT "TBD" started in 240ms - Started 144 of 181 services (55 services are lazy, passive or on-demand)
> 14:39:17,452 ERROR [stderr] (Controller Boot Thread) Controller Boot Thread releasing lock on 565478949
> 14:39:17,713 ERROR [org.xnio.listener] (Remoting "fedorka:MANAGEMENT" read-1) A channel event listener threw an exception: java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method) [rt.jar:1.7.0_13]
> at java.lang.Thread.start(Thread.java:691) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360) [rt.jar:1.7.0_13]
> at org.xnio.XnioWorker.execute(XnioWorker.java:724) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:218) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:518)
> And if look at the thread dump of the server process, I see lots of acceptor and poller threads. See the attached thread dump.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6802) acceptor and poller threads not destroyed when reloading
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/AS7-6802?page=com.atlassian.jira.plugin.s... ]
Alexey Loubyansky commented on AS7-6802:
----------------------------------------
The whole server. Standalone in this case.
Actually, I used the reload cli command, which does the following:
- send the :reload operation request to the controller;
- wait for the current connection to the controller to close (as part of the server shutdown);
- establish a new connection to the reloaded server;
- return control to the client.
And the client would execute the reload command again, over and over.
> acceptor and poller threads not destroyed when reloading
> --------------------------------------------------------
>
> Key: AS7-6802
> URL: https://issues.jboss.org/browse/AS7-6802
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Fedora 18
> java version "1.7.0_13"
> Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
> Reporter: Alexey Loubyansky
> Assignee: Remy Maucherat
> Attachments: server_thread_dump.txt
>
>
> I'm testing the reload operation. At some point the server becomes unresponsive. One of the reasons is
> 14:39:17,452 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 8.0.0.Alpha1-SNAPSHOT "TBD" started in 240ms - Started 144 of 181 services (55 services are lazy, passive or on-demand)
> 14:39:17,452 ERROR [stderr] (Controller Boot Thread) Controller Boot Thread releasing lock on 565478949
> 14:39:17,713 ERROR [org.xnio.listener] (Remoting "fedorka:MANAGEMENT" read-1) A channel event listener threw an exception: java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method) [rt.jar:1.7.0_13]
> at java.lang.Thread.start(Thread.java:691) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360) [rt.jar:1.7.0_13]
> at org.xnio.XnioWorker.execute(XnioWorker.java:724) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:218) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:518)
> And if look at the thread dump of the server process, I see lots of acceptor and poller threads. See the attached thread dump.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6699) AS7 messaging resources throws NPE when hornetq-server is a backup
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6699?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6699:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 918131|https://bugzilla.redhat.com/show_bug.cgi?id=918131] from NEW to POST
> AS7 messaging resources throws NPE when hornetq-server is a backup
> ------------------------------------------------------------------
>
> Key: AS7-6699
> URL: https://issues.jboss.org/browse/AS7-6699
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Alpha1
>
>
> steps to reproduce:
> Configure AS7's hornetq-server to be a backup ready for failover.
> Run AS7 standalone-full configuration with hornetq-server configured to be a backup:
> {noformat}
> <hornetq-server>
> <backup>true</backup>
> ...
> {noformat}
> The AS7 will start, its hornetq-server too *but* it will not be active:
> {noformat}
> 18:24:56,527 INFO [org.hornetq.core.server] (HQ119001: Activation for server HornetQServerImpl::serverUUID=349065dd-87f2-11e2-911d-f19bf97ea7a7) HQ002211: HornetQ Backup Server version 2.3.0.CR1 (buzzzzz!, 122) [349065dd-87f2-11e2-911d-f19bf97ea7a7] started, waiting live to fail before it gets active
> {noformat}
> The hornetq server will not become active until a live node fails. When this occurs, the server will become active, accept connection, create core and JMS resources etc.
> The issue is that any runtime operation on a hornetq-server's children will fail.
> The runtime operations rely on HornetQ's management resource (eg TopicControl, QueueControl) and these objects are not available until HornetQ server is active.
> For AS7 integration that means that we must somehow prevent any runtime changes to any hornetq-server's children resources for a passive server. There are no corresponding runtime resources in HornetQ for them.
> Additionnaly, hornetq-server does not expose the "active" runtime attribute to know whether the server is active.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6802) acceptor and poller threads not destroyed when reloading
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/AS7-6802?page=com.atlassian.jira.plugin.s... ]
Remy Maucherat commented on AS7-6802:
-------------------------------------
"Reload operation" means stopping and starting repeatedly the web subsystem ?
> acceptor and poller threads not destroyed when reloading
> --------------------------------------------------------
>
> Key: AS7-6802
> URL: https://issues.jboss.org/browse/AS7-6802
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Fedora 18
> java version "1.7.0_13"
> Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
> Reporter: Alexey Loubyansky
> Assignee: Remy Maucherat
> Attachments: server_thread_dump.txt
>
>
> I'm testing the reload operation. At some point the server becomes unresponsive. One of the reasons is
> 14:39:17,452 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 8.0.0.Alpha1-SNAPSHOT "TBD" started in 240ms - Started 144 of 181 services (55 services are lazy, passive or on-demand)
> 14:39:17,452 ERROR [stderr] (Controller Boot Thread) Controller Boot Thread releasing lock on 565478949
> 14:39:17,713 ERROR [org.xnio.listener] (Remoting "fedorka:MANAGEMENT" read-1) A channel event listener threw an exception: java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method) [rt.jar:1.7.0_13]
> at java.lang.Thread.start(Thread.java:691) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360) [rt.jar:1.7.0_13]
> at org.xnio.XnioWorker.execute(XnioWorker.java:724) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:218) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) [jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61) [xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:518)
> And if look at the thread dump of the server process, I see lots of acceptor and poller threads. See the attached thread dump.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months