Re: does the underlying implementation (not public) of DatagramSocketImp's send receive method busy wait
On 18/12/2017 21:24, Paul Marks wrote: So if the kernel decides to block, the thread will be suspended (consuming no CPU) until it's done. However, the UDP protocol has no concept of flow control, so blasting out packets without any rate limit or acknowledgement mechanism is not a good idea. If you saturate a link in the network, sendto() is not obligated to block, or provide any feedback whatsoever. That's right and you'll find that most kernels will just discard the packet so the send never blocks. -Alan
Re: does the underlying implementation (not public) of DatagramSocketImp's send receive method busy wait
Aside from the fact that I should watch out for blasting too many packets at once, and realizing that this one "server/controller" machine has to control 100 or more client receiving machines, with smallish packets, is there any advantage at all relative to the linux kernel in having more than one UDP port open for sending out? I.e. say the controller has a queue of 200 packets to spray out, is it sufficient to use just one java thread and one UDP outbound port, or would it give the kernel more throughput to send out the packets with 5 threads and 5 sockets or even more? The packets are 10 bytes and/or 140 bytes. On Tuesday, December 19, 2017, 2:53:30 AM PST, Alan Bateman wrote: On 18/12/2017 21:24, Paul Marks wrote: So if the kernel decides to block, the thread will be suspended (consuming no CPU) until it's done. However, the UDP protocol has no concept of flow control, so blasting out packets without any rate limit or acknowledgement mechanism is not a good idea. If you saturate a link in the network, sendto() is not obligated to block, or provide any feedback whatsoever. That's right and you'll find that most kernels will just discard the packet so the send never blocks. -Alan
Re: RFR: 8192966 HttpClient should reuse TCP connection for h2c connections [jdk10]
This is follow on from a previous review of the same bug fix. The fix is now targeted specifically for jdk10. A slightly different approach is taken this time. But, your comment below is incorporated into the new version Daniel Webrev: http://cr.openjdk.java.net/~michaelm/8192966/webrev.2/ Thanks Michael On 12/12/2017, 13:32, Michael McMahon wrote: Thanks Daniel. I'm looking at this change again as I have noticed the behavior when multiple https requests are initiated might not be what we want. I'll post another webrev later. - Michael On 12/12/2017, 10:32, Daniel Fuchs wrote: Hi Michael, I wonder whether Http2Connection::closeStream would be a better place to call Stream::checkConnectionClosure? If not then shouldn't it be called in Stream::release as well? best regards, -- daniel On 12/12/2017 10:07, Michael McMahon wrote: http://cr.openjdk.java.net/~michaelm/8192966/webrev.1/ Thanks, Michael.
Re: RFR: 8192966 HttpClient should reuse TCP connection for h2c connections [jdk10]
Hi Michael, On 19/12/2017 14:20, Michael McMahon wrote: This is follow on from a previous review of the same bug fix. The fix is now targeted specifically for jdk10. A slightly different approach is taken this time. But, your comment below is incorporated into the new version Daniel Webrev: http://cr.openjdk.java.net/~michaelm/8192966/webrev.2/ This looks much better to me! best regards, -- daniel Thanks Michael On 12/12/2017, 13:32, Michael McMahon wrote: Thanks Daniel. I'm looking at this change again as I have noticed the behavior when multiple https requests are initiated might not be what we want. I'll post another webrev later. - Michael On 12/12/2017, 10:32, Daniel Fuchs wrote: Hi Michael, I wonder whether Http2Connection::closeStream would be a better place to call Stream::checkConnectionClosure? If not then shouldn't it be called in Stream::release as well? best regards, -- daniel On 12/12/2017 10:07, Michael McMahon wrote: http://cr.openjdk.java.net/~michaelm/8192966/webrev.1/ Thanks, Michael.
AW: does the underlying implementation (not public) ofDatagramSocketImp's send receive method busy wait
Hello, it is a bit unlikely that there is much difference (especially for as low as 200 packets), but I would recommend you actually try it with your specific traffic pattern and System load. Not much a Java developer can say about various Linux kernel versions and their drivers. Gruss Bernd -- http://bernd.eckenfels.net Von: Andy Nuss Gesendet: Dienstag, 19. Dezember 2017 15:31 An: Alan Bateman; net-dev@openjdk.java.net; Paul Marks Betreff: Re: does the underlying implementation (not public) ofDatagramSocketImp's send receive method busy wait Aside from the fact that I should watch out for blasting too many packets at once, and realizing that this one "server/controller" machine has to control 100 or more client receiving machines, with smallish packets, is there any advantage at all relative to the linux kernel in having more than one UDP port open for sending out? I.e. say the controller has a queue of 200 packets to spray out, is it sufficient to use just one java thread and one UDP outbound port, or would it give the kernel more throughput to send out the packets with 5 threads and 5 sockets or even more? The packets are 10 bytes and/or 140 bytes. On Tuesday, December 19, 2017, 2:53:30 AM PST, Alan Bateman wrote: On 18/12/2017 21:24, Paul Marks wrote: So if the kernel decides to block, the thread will be suspended (consuming no CPU) until it's done. However, the UDP protocol has no concept of flow control, so blasting out packets without any rate limit or acknowledgement mechanism is not a good idea. If you saturate a link in the network, sendto() is not obligated to block, or provide any feedback whatsoever. That's right and you'll find that most kernels will just discard the packet so the send never blocks. -Alan
