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.
Thanks Brian. I wonder why the same doesn't happen on 6.4.5.CP.CR2...
Jiri Pallich <jpallich> updated the status of jira JBEAP-1870 to Closed
Verified with EAP 6.4.10.CP.CR2
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.