On 11/03/2020 16:54, Patrick Concannon wrote:
Hi,
I've included those additional changes, and they can be found in the
new webrev below.
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/
Thanks for the update, looks good. I assume the updates to the IPSupport
infra isn't need
Regarding the test to check that large datagrams are sent and received
correctly across a network: I've created a new issue for it and
included the link below.
https://bugs.openjdk.java.net/browse/JDK-8240901
Kind regards,
Patrick
On 11/03/2020 16:54, Patrick Concannon wrote:
Hi,
I've inc
Hi,
I've included those additional changes, and they can be found in the new
webrev below.
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/
Kind regards,
Patrick
On 11/03/2020 12:27, Daniel Fuchs wrote:
Hi Alan,
On 11/03/2020 12:08, Alan Bateman wrote:
Do we really? I a
Hi Alan,
On 11/03/2020 12:08, Alan Bateman wrote:
Do we really? I am not sure we do.
We just want to verify that we don't get the "packet too large"
exception caused by the SO_SNDBUF buffer being too small.
It would be great if we had a test to send large datagrams on the
network as that is the
On 11/03/2020 10:58, Daniel Fuchs wrote:
:
testSend sends to the loopback address but I think we need this test
to send datagrams on the network (sending to the loopback is okay too
but I think you want this test to send a datagram on the network
because we want fragmentation on the network(.
Hi Alan,
On 10/03/2020 19:59, Alan Bateman wrote:
On 10/03/2020 18:32, Patrick Concannon wrote:
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.02
Thanks for adding a test for getOption(SO_SNDBUF). That test
(testGetOption) should be checking that SO_SNDBUF is >= expected value
Hello,
Depending on the test environment you don't need much native tools. You can use
java.io.File to open /proc/thread-self to get the TID and use ProcessBuilder to
execute the kill command.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: net-dev im Auftrag vo
On 11/03/2020 08:09, Vyom Tewari26 wrote:
Hi Alan,
Thanks for comment yes for >=JDK13 we are using new socket impl which
does not have this problem, i am not planning to wright a test, to
test this issue we need to get the native thread ID then we have to
interrupt the thread to see if JDK c
Hi Alan,
Thanks for comment yes for >=JDK13 we are using new socket impl which does not have this problem, i am not planning to wright a test, to test this issue we need to get the native thread ID then we have to interrupt the thread to see if JDK code is behaving as expected.
I tested this
Vyom,
Are you planning to create a native test for this? I realize the fix you
are discussing here isn't too interesting for >= JDK 13 but I think it
could be useful to ensure that we have a test that signals threads in
all of the blocking operations (connect might be tricky butt at least
rea
10 matches
Mail list logo
