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.