I am performing a Maven build on my client’s Java codebase, and one of the test suites is failing. The error reported in the logs is the same as what I find when I step through the code with the NetBeans debugger.
The native function java.net.PlainDatagramSocketImpl.send() is throwing a BindException – “Cannot assign requested address”. I cannot step deeper into the code than this, since it is a native function.
At a higher level, the code is performing a basic test of the network.
DatagramSocket ds = new DatagramSocket(service.getNetworkConfiguration().getBindSocketAddress().getPort() + 100);
InetSocketAddress bindSocketAddress = service.getNetworkConfiguration().getBindSocketAddress();
ds.send(new DatagramPacket(message, message.length, bindSocketAddress.getAddress(), bindSocketAddress.getPort()));
The IP address returned by service, and therefore contained in bindSocketAddress is, as noted, 0.0.0.0 – I have tried different ports (32168, 22332, 1234), all with the same error.
The + 100 that appears in the definition of the DatagramSocket port is apparently intentional, and this test suite has been succeeding for a long time for others, with that in place.
I am running on Windows 7, 64-bit.
I have disabled the firewall and antivirus on the local machine, and I have run netstat -a and I do not see any of the ports I’ve used in the list of bound ports.
Is this likely to be an issue with my Windows configuration or even my router? Perhaps my Java configuration in some way? Any suggestions would be highly appreciated.
Follow up: I receive the IDENTICAL error when running on a CentOS 5.5 virtual machine. It still may be a Windows 7 configuration issue, though, since the VM guest is running on the Windows 7 host – sharing its internet connection. (bridged)
Follow up #2 (see 4th comment): It seems invalid to have the RECIPIENT be 0.0.0.0; in fact, a comment in the JDK (InetAddress.java) says: The unspecified address (also called anylocal or wildcard address) must not be used as the destination address of an IP packet where the wildcard address is 0.0.0.0. I changed the code to use “localhost” (see 4th comment) and it solves the problem. However, the above code might be valid for a reason I don’t understand; when I clarify with the developers of the code, I will post a follow-up or an answer.
UPDATE (Mar 1, 2012): It turns out (in retrospect) that in fact, the code in question was simply a bug on the previous programmers’ parts. My true misunderstanding was entirely unrelated to the topic of the question.
The explanation is: every time I built the Java code, I ran the associated unit tests that were built into the system. I did not, at that time, realize that it was possible to build the source code, yet bypass the unit tests. It turns out that another programmer on the team had built the code (successfully), but skipped the unit tests (and failed to notice this error); then committed the code to source control, believing that it was correct. Other programmers were also in the habit of building the code while skipping the unit tests. Therefore, the bug was not caught for a few weeks. However, I did perform the unit tests, and received this supposedly working code from source control while it still contained the bug. I did not ask others on the team about the bug because at that time, I believed it was my responsibility to understand Java sufficiently without taking the time of other programmers on the team, and I assumed it was my misunderstanding because I assumed that others were not receiving the error in the unit tests.
Please see my “Update” – this question is moot.
Look at my long comment for a fuller explanation.
I am leaving the question here in case the “Update” at the end of the question, which is unrelated to the topic of the question itself, is discovered by someone for whom it proves useful.