-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8264200: java/nio/channels/DatagramChannel/SRTest.java fails intermittently #3354
Conversation
👋 Welcome back ccleary! A progress list of the required criteria for merging this PR into |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good cleanup overall.
newDecoder().decode(bb); | ||
log.println("From: "+sa+ " said " +cb); | ||
dc.close(); | ||
CharBuffer cb = StandardCharsets.US_ASCII.newDecoder().decode(bb); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a charset is used, then it should be used consistently - in both classic and nio readers and writers.
That is, whenever String::getBytes
is called or new String(byte[])
is called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, I think I will opt for using US_ASCII
across all of the classic and nio readers/writers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using an 8-bit charset might be a better choice, US_ASCII is only 7bit and might produce some unmappable characters.
ISO_8859_1 would be a better choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. Is there any reason then why UTF-8 would be used over ISO_8859_1 then, given what you said above about character mapping? Or vice-versa
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The message sent by the writer is "hello" - it only contains ASCII characters, so any of US-ASCII, UTF-8, or ISO-8859-1, which are all compatible with ASCII (meaning: all these encode ASCII chars in the same way) would work.
In fact any charset in which "hello" is mappable would work. We simply need to make sure to use the same charset when encoding or decoding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the test is for Datagram send and receive all the data is in byte arrays or equivalent.
The entire test could be written using only byte arrays (no Strings, Charsets or conversions) and omit that possibility of confusion about what the test is doing.
(And there's no need to change anything).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright then so I will continue to to just use US_ASCII
in this test as "hello" is mappable with it. Encoding and Decoding the string will be done with US_ASCII
. Appreciate the feedback guys, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Conor. Yes - we could work with byte arrays but strings are easier to print & log & more human friendly...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, but please use getBytes(StandardCharsets.US_ASCII) to get the bytes avoiding ambiguity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most recent commit performs a static import of the charset with import static java.nio.charset.StandardCharsets.US_ASCII;
. I feel that it is clear enough and keeps references to the Charset concise.
@c-cleary This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 75 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@dfuch, @RogerRiggs, @msheppar) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
@@ -192,10 +192,10 @@ public void run() { | |||
byte[] buf = new byte[256]; | |||
DatagramPacket dp = new DatagramPacket(buf, buf.length); | |||
ds.receive(dp); | |||
String received = new String(dp.getData()); | |||
String received = new String(dp.getData(), US_ASCII); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not quite correct, you need to take into account the offset and length of the received data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah... good spot, this results in a needlessly long string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing to String received = new String(dp.getData(), 0, DATA_STRING.length(), US_ASCII);
seems to correct the issue, using a constant DATA_STRING
I note in the senders (ClassicWriter and NioWriter) there are two send invocation while in the receivers there is only one receive invocation. That raises a question as to why there are two send invocations, and which of these a receiver processes - no way of telling if the first has been lost? now a bit of conjecture: |
@msheppar it seems to me that the duplicate send is a feature from the old test which may no longer be needed. In the old test, the
This
I would subsequently guess that this serves to be extra sure that a Datagram reaches the reader. Assuming the first packet doesnt make it (probably unlikely), waiting for 50 milliseconds ensures that the reader is at the very least waiting to receive. |
Yes, the original test had this conundrum. As such there is no synchronicity between the sender and the receiver in the test, other than the receiver may block indefinitely if a datagram is not received, which is now diminished by using the loopback as the receiver's bind address and as the destination address. But the rationale for invoking two sends and one receive is obscure and still remains a potential, if somewhat rare, problem. So I'd proffer some symmetry between the sender and receiver with one send and one receive, or that the receiver should remain extant until the sender has terminated, as such it would wait on "signal" from the sender that it has finished. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
another observation on the test structure is that each sender is bound to wildcard address, ClassicWriter explicitly through constructor and the NioWriter implicitly when it invokes send - the DatagramChannel is unbound initially, no explicit bind is invoked, and when send is invoked then the underlying socket is bound to wildcard during that call flow. Both ClassicWriter and NioWriter constructors take a port, which is the destination port of the recipient rather than a port to which they'll bind -- maybe a rename of the parameter to dstPort ? |
@msheppar I would rather not change the way that the senders are bound, unless it is verified that this is causing problems and we are able to figure out why. |
Most recent commit makes this change as suggested by @msheppar |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
/integrate |
/integrate |
/sponsor |
@AlekseiEfimov @c-cleary Since your change was applied there have been 91 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 784f1c1. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Description
SRTest.java has been seen to fail intermittently in a similar manner to other recent failures in DatagramChannel tests. With SRTest.java, these failures are associated with a number of issues listed below. Note that XReader refers to both ClassicReader and NioReader classes. Likewise for XWriter.
Issues
DatagramPacket
if an XSender has not sent one.Fixes
To Address these issues, the following was done respective to the order of the Issues above:
testng/othervm
and uses its own thread pool. Note that the change to testng was not absolutely essential but means that if one test case fails the others will still be run which could provide useful information on why a failure occured.Autocloseable
and are declared within a try-with-resources block for each test case. As well as this, the test cases are now executed withCompleteableFuture.allOf(futures)
such that if any Reader or Writer throws an exception during execution, the threads will exit in a safe manner and the exception concerned will be thrown (wrapped in aCompletionException
).@run
astestng/othervm/timeout=20
tag in seconds. See Action Options in Jtreg docs here.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3354/head:pull/3354
$ git checkout pull/3354
Update a local copy of the PR:
$ git checkout pull/3354
$ git pull https://git.openjdk.java.net/jdk pull/3354/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 3354
View PR using the GUI difftool:
$ git pr show -t 3354
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3354.diff