Description of problem:
The ManagedDatagramSocketBinding.close method throws NPE when called from the parent's constructor (which can happen at least on Java 8).
Version-Release number of selected component (if applicable):
6.4.5.CP.CR2
How reproducible:
Always
Steps to Reproduce:
0. make sure you use Java 8!
1. unzip jboss-eap-6.4.0.zip
2. ./jboss-eap-6.4/bin/jboss-cli.sh --command="patch apply jboss-eap-6.4.5.CP.CR2-patch.zip"
3. cp clusterbench-ee6.ear ./jboss-eap-6.4/standalone/deployments/ # any distributable app will do
4. mv jboss-eap-6.4 jboss-eap-6.4-node1
5. cp -a jboss-eap-6.4-node1 jboss-eap-6.4-node2
6. in jboss-eap-6.4-node2/standalone/configuration/standalone-ha.xml, subtract 100 from both the port numbers in the "jgroups-udp" socket binding
7. ./jboss-eap-6.4-node1/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1
8. ./jboss-eap-6.4-node2/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100
This will cause a port clash of the JGroups UDP sockets, but all other sockets won't collide (without that, the server wouldn't even start).
Actual results:
Caused by: org.infinispan.CacheException: Unable to start JGroups Channel
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:209)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:198)
...
Caused by: java.lang.NullPointerException
at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
at java.net.DatagramSocket.<init>(DatagramSocket.java:245) [rt.jar:1.8.0_66]
at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
...
Expected results:
No NPE.
Additional info:
Granted, the reproducing scenario is fairly artificial, but I guess that there are other more realistic scenarios and a NPE is never appropriate anyway.
Turns out that with EAP 6.4.4, the procedure described in comment 0 works just fine. Even though both cluster nodes are configured to have a port collision, one of them somehow magically increments a port number by 1. Weird.
(In reply to Ladislav Thon from comment #2)
> Turns out that with EAP 6.4.4, the procedure described in comment 0 works
> just fine. Even though both cluster nodes are configured to have a port
> collision, one of them somehow magically increments a port number by 1.
> Weird.
Magic is probably from this:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/UDP.java#L490
Looks like the default port_range is 50. If set to 0 the magic won't happen.