Description of problem: See https://issues.jboss.org/browse/JBEAP-1882 Version-Release number of selected component (if applicable): 6.4.5.CP.CR2 How reproducible: Always, but it's a bit of a hack. Steps to Reproduce: 1. install EAP 6.4.5.CP.CR2 (unzip 6.4.0 and apply a patch) 2. replace the jboss-as-clustering-jgroups JAR in the org.jboss.as.clustering.jgroups module with a newly compiled one that contains this change: https://github.com/wildfly/wildfly/commit/36f5bd99c8 (basically, so that the datagram socket is registered as _unnamed_ instead of named) -- this is to test the unnamed registry, which is otherwise practically unused 3. copy a distributable app into standalone/deployments/ 4. start and stop the server (See also comments in JBEAP-1882 for more context.) Actual results: 17:51:01,108 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 14) failed destroying the protocol stack: java.lang.IllegalArgumentException: port out of range:-1 at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:123) [rt.jar:1.6.0_45] at java.net.InetSocketAddress.<init>(InetSocketAddress.java:165) [rt.jar:1.6.0_45] at java.net.DatagramSocket.getLocalSocketAddress(DatagramSocket.java:545) [rt.jar:1.6.0_45] at org.jboss.as.network.ManagedDatagramSocketBinding.getBindAddress(ManagedDatagramSocketBinding.java:56) [jboss-as-network-7.5.5.Final-redhat-2.jar:7.5.5.Final-redhat-2] at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:498) [jboss-as-network-7.5.5.Final-redhat-2.jar:7.5.5.Final-redhat-2] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73) [jboss-as-network-7.5.5.Final-redhat-2.jar:7.5.5.Final-redhat-2] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:147) at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:576) at org.jgroups.protocols.UDP.destroySockets(UDP.java:397) at org.jgroups.protocols.UDP.destroy(UDP.java:259) at org.jgroups.stack.ProtocolStack.destroy(ProtocolStack.java:884) at org.jgroups.JChannel.stopStack(JChannel.java:912) at org.jgroups.JChannel._close(JChannel.java:897) at org.jgroups.JChannel.close(JChannel.java:374) at org.jboss.as.clustering.jgroups.MuxChannel.destroy(MuxChannel.java:77) at org.jboss.as.clustering.jgroups.subsystem.ChannelService.stop(ChannelService.java:89) at org.jboss.as.clustering.msc.AsynchronousService$2.run(AsynchronousService.java:113) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1] This is a different exception from the one in JBEAP-1882, but it comes from the same code. Expected results: No such exception, the unnamed registry should handle unbound sockets gracefully. Additional info: IMHO, this is very unlikely to have an impact in real world.
Jiri Pallich <jpallich> updated the status of jira JBEAP-1882 to Closed
back to the pool. This is already in upstream. https://issues.jboss.org/browse/WFCORE-1127 It should be backported.