Uh oh!
There was an error while loading. Please reload this page.
src: add trace points to dns - #21840
Conversation
There was a problem hiding this comment.
This looks odd … this means that trace_name is initialized once and not changed afterwards? What if this function gets called with instances of QueryWrap that have different names?
I think things might end up being easier if you store the original const char* itself on the class and always pass that to the trace macros. That might require the string to be given at compile time, but I’d think that’s okay.
There was a problem hiding this comment.
Thanks for pointing it out. I will need to fix it.
There was a problem hiding this comment.
does this change cause any external JS API interface change? I guess not.
There was a problem hiding this comment.
does it make sense to wrap all these callbacks into common.mustCall semantic?
There was a problem hiding this comment.
Thanks for the comments. The callbacks are not significant in the trace log test case. There are existing test files that cover general dns features. The main focus here is to ensure an expected trace log is written to the trace output file. I did break the all-in-one test into individual tests so it will be easier to pinpoint the problem should an error occurs.
There was a problem hiding this comment.
makes sense, thanks. My experience showed that issues are often caught by test cases that were not designed to test such issues. Moreover the semantic which we are talking about is present in every piece of test code that has a completion handler callback. But definitely not a reason for tests to overload cases, and I am fine here.
There was a problem hiding this comment.
Let's make the category on these node.dns.native. Once we have the V8 trace instrinsic landed they will be paired up with the node.dns.js side.
Also, there's a macro to make the naming easier... e.g. TRACING_CATEGORY_NODE2(dns, native) expands to node,node.dns,node.dns.native to ensure we have a proper hierarchy.
There was a problem hiding this comment.
Thanks for the comments. I changed the category to node.dns.native, also started to use TRACING_CATEGORY_NODE2(dns, native).
There was a problem hiding this comment.
This test should probably go into test/internet?
There was a problem hiding this comment.
Honestly I are not sure the technical differences between test/internet and test/parallel. I saw dns test code in both folders. For now, I put this under test/parallel, along with other test-trace-events-xxx test files. I don't mind to move if it should go to test/internet by definition.
There was a problem hiding this comment.
@chinhuang007 Generally, test that reach out to random internet servers should go into test/internet – think of it as tests that could be affected by e.g. a firewall. These tests aren’t run as part of a standard make test, though.
There are DNS tests in test/parallel, but (I think) most of those use a DNS mock implementation (e.g. test/parallel/test-dns-resolveany.js) – that’s nice, because it means that the test is fully self-contained and doesn’t do any networking outside the local host, but it also comes with some overhead when writing the test.
It’s a tradeoff, and you can choose to go either route, but if you keep the test as it is, please move it. :)
There was a problem hiding this comment.
Okay, moved the test code to test/parallel. Thanks for your explanation!
33668dd to
d7ede7aComparechinhuang007
commented
Jul 23, 2018
What's the next step to move it forward? |
chinhuang007
commented
Jul 25, 2018
If no changes are needed, can someone help start the merge/land process? |
addaleax
commented
Jul 25, 2018
@chinhuang007 I think this is technically ready, but /cc @joyeecheung because https://github.com/nodejs/node/pull/21939/files#diff-5a543a2c1d958ec924db11553ecfb703 also adds string identifiers to all of the different query classes |
849f83b to
128e866CompareThere was a problem hiding this comment.
Is there a reason these are ip4 and ip6 instead of ipv4 and ipv6? (like the ones in GetHostByAddrWrap)
There was a problem hiding this comment.
Thanks for catching it. Just fixed it.
joyeecheung
commented
Jul 26, 2018
It should be orthogonal to #21939 since the naming here is for time spent on (JS-API-ish) operations (measured in microseconds) instead of internal types of chunks in memory (measured in bytes). |
7d401e2 to
420daf0Comparechinhuang007
commented
Jul 27, 2018
Thanks, @joyeecheung for the review and comments. I fixed a CI problem for osx. Can someone help start a new CI? |
gireeshpunathil
commented
Jul 27, 2018
chinhuang007
commented
Aug 1, 2018
The CI build problem doesn't seem related this PR. Can someone start a new CI to see if the problem is repeatable? |
yhwang
commented
Aug 1, 2018
chinhuang007
commented
Aug 6, 2018
Please let me know if anything else needs to be done before this PR can be merged/landed. Thanks! |
jasnell
commented
Aug 12, 2018
yhwang
commented
Aug 16, 2018
chinhuang007
commented
Aug 17, 2018
@jasnell Thanks for starting the CI. Somehow some tests failed on unrelated build issues. I wonder if you can help merge/land it? |
jasnell
commented
Aug 18, 2018
addaleax
commented
Aug 18, 2018
Once again, CI: https://ci.nodejs.org/job/node-test-pull-request/16544/ |
joyeecheung
commented
Aug 20, 2018
This PR needs a rebase against master to avoid the git failure in the CI. |
Add trace points to dns under node.dns.native category. Emit trace events for dns operations. Use the nestable async events instead of deprecated ones. Include test code to verify the trace log. The trace name is stored as const char* class variable. The test code is to check each operation in separate sync processes. Refs: nodejs#19157
60cf701 to
7ceedb9Comparechinhuang007
commented
Aug 20, 2018
Thanks for the CIs and comments. I just rebased and locally tested. Hope the next CI will be clean. |
joyeecheung
commented
Aug 20, 2018
addaleax
commented
Aug 20, 2018
Only one unrelated FreeBSD failure remaining 😄 Resume build: https://ci.nodejs.org/job/node-test-pull-request/16619/ |
chinhuang007
commented
Sep 2, 2018
Just rebased and passed tests. Do we need to start a new CI, hoping no unrelated errors? Please advice what I can do to help land it. |
addaleax
commented
Sep 2, 2018
@chinhuang007 Sorry, all that was needed was a ping to remind us – landed in b366de5! |
Add trace points to dns under node.dns.native category. Emit trace events for dns operations. Use the nestable async events instead of deprecated ones. Include test code to verify the trace log. The trace name is stored as const char* class variable. The test code is to check each operation in separate sync processes. Refs: #19157 PR-URL: #21840 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Since this test is in Update: Fix PR #22674 |
Add trace points to dns under node.dns.native category. Emit trace events for dns operations. Use the nestable async events instead of deprecated ones. Include test code to verify the trace log. The trace name is stored as const char* class variable. The test code is to check each operation in separate sync processes. Refs: #19157 PR-URL: #21840 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Add trace points to dns under node.dns.native category. Emit trace events for dns operations. Use the nestable async events instead of deprecated ones. Include test code to verify the trace log. The trace name is stored as const char* class variable. The test code is to check each operation in separate sync processes. Refs: #19157 PR-URL: #21840 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
As implemented in nodejs#21840, dns can emit trace events when the category is enabled. This PR just add it to the documentation.
As implemented in nodejs#21840, dns can emit trace events when the category is enabled. This PR just add it to the documentation. PR-URL: nodejs#28100 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Add trace points to dns under node.dns category.
Emit trace events for dns operations. Use the
nestable async events instead of deprecated ones.
Include test code to verify the trace log.
Refs: #19157
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes