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: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 | |
Supported by Python Software Foundation,
Powered by Roundup