Message3131

Author amak
Recipients amak, asterio
Date 2008-04-07.21:39:32
SpamBayes Score 0.030138517
Marked as misclassified No
Message-id <1207604372.45.0.218804633831.issue1018@psf.upfronthosting.co.za>
In-reply-to
Content
Actually, the bug is partially fixed already, but not in 2.2.1. The fix
is checked into the 2.2 release branch, and will appear in 2.2.2. You
could of course download the latest version from SVN (URL below).

If you use the latest (fixed) module, when the socket is in either
blocking or non-blocking mode, the fixed code uses the java.nio apis,
which do not present this problem.

However, if you change your socket into timeout mode, then the old
java.net code path is used, and the bug still appears. Change the
setblocking(1) call before the udp_server.recvfrom, and you will see the
bug re-appear.

This seems to be caused by the the DatagramPacket.getAddress() call
returning null, which prevents getting at the information about from
whence the packet was received.

I have yet to ascertain why this happens, but think this may be a bug in
java DatagramPackets, relating to the fact that the DatagramChannel is
created with the java.nio APIs, but the packet is received using the
java.net.

I will investigate further.
History
Date User Action Args
2008-04-07 21:39:32amaksetspambayes_score: 0.0301385 -> 0.030138517
recipients: + amak, asterio
2008-04-07 21:39:32amaksetspambayes_score: 0.0301385 -> 0.0301385
messageid: <1207604372.45.0.218804633831.issue1018@psf.upfronthosting.co.za>
2008-04-07 21:39:32amaklinkissue1018 messages
2008-04-07 21:39:32amakcreate