Bug 1280235 - [GSS](6.4.z) ManagedDatagramSocketBinding.close throws NPE
[GSS](6.4.z) ManagedDatagramSocketBinding.close throws NPE
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
6.4.5
Unspecified Unspecified
high Severity high
: CR1
: EAP 6.4.10
Assigned To: Enrique Gonzalez Martinez
Ladislav Thon
: Regression
Depends On:
Blocks: eap6410-payload
  Show dependency treegraph
 
Reported: 2015-11-11 05:02 EST by Ladislav Thon
Modified: 2017-01-17 07:58 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-17 07:58:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBEAP-1870 Major Closed ManagedDatagramSocketBinding throw NPE 2017-03-21 08:00 EDT
JBoss Issue Tracker WFCORE-1119 Major Resolved ManagedDatagramSocketBinding throw NPE 2017-03-21 08:00 EDT

  None (edit)
Description Ladislav Thon 2015-11-11 05:02:01 EST
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.
Comment 2 Ladislav Thon 2015-11-13 09:37:51 EST
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.
Comment 4 Brian Stansberry 2015-11-13 09:57:54 EST
(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.
Comment 5 Ladislav Thon 2015-11-13 10:09:27 EST
Thanks Brian. I wonder why the same doesn't happen on 6.4.5.CP.CR2...
Comment 9 JBoss JIRA Server 2016-06-14 07:37:07 EDT
Jiri Pallich <jpallich@redhat.com> updated the status of jira JBEAP-1870 to Closed
Comment 14 Michael Cada 2016-08-23 03:21:53 EDT
Verified with EAP 6.4.10.CP.CR2
Comment 15 Petr Penicka 2017-01-17 07:58:33 EST
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Note You need to log in before you can comment on or make changes to this bug.