Message3131
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. |
|
Date |
User |
Action |
Args |
2008-04-07 21:39:32 | amak | set | spambayes_score: 0.0301385 -> 0.030138517 recipients:
+ amak, asterio |
2008-04-07 21:39:32 | amak | set | spambayes_score: 0.0301385 -> 0.0301385 messageid: <1207604372.45.0.218804633831.issue1018@psf.upfronthosting.co.za> |
2008-04-07 21:39:32 | amak | link | issue1018 messages |
2008-04-07 21:39:32 | amak | create | |
|