Inline NetLog IPv6 reachability events.

Inline NetLog IPv6 reachability events.

The events create a lot of log spew.  They used to be done independently
of DNS resolutions, but now that they're done on every resolution, no
need to make them separate events.

BUG=none

Committed: https://crrev.com/04ffcf25e708f3835ad4a48af044b2fb10aa6c27
Cr-Commit-Position: refs/heads/master@{#326823}

[mmenke, 2015-02-18 22:14:22]

Patchset #2 (id:20001) has been deleted

[mmenke, 2015-02-20 18:52:24]

mmenke@chromium.org changed reviewers:
+ ttuttle@chromium.org

[mmenke, 2015-02-20 18:52:25]

ttuttle:  WDYT?  The downside is that these events appear with the parent event
(Like the HTTP_STREAM_JOB), rather than the HOST_RESOLVER_IMPL_JOB itself, since
we haven't created the job yet (And can't, until we determine if we're doing an
IPv6 lookup or not).

[Deprecated (see juliatuttle), 2015-02-24 16:42:50]

On 2015/02/20 18:52:25, mmenke wrote:
> ttuttle:  WDYT?  The downside is that these events appear with the parent
event
> (Like the HTTP_STREAM_JOB), rather than the HOST_RESOLVER_IMPL_JOB itself,
since
> we haven't created the job yet (And can't, until we determine if we're doing
an
> IPv6 lookup or not).

Code itself looks good.

My only concern is how hard it will be to find them -- one of the benefits of
exposing them as separate events is that it is easy for someone to look in the
net logs and see why their browser is 'making' so many connections to our DNS
servers.

[mmenke, 2015-02-26 22:23:13]

On 2015/02/24 16:42:50, ttuttle wrote:
> On 2015/02/20 18:52:25, mmenke wrote:
> > ttuttle:  WDYT?  The downside is that these events appear with the parent
> event
> > (Like the HTTP_STREAM_JOB), rather than the HOST_RESOLVER_IMPL_JOB itself,
> since
> > we haven't created the job yet (And can't, until we determine if we're doing
> an
> > IPv6 lookup or not).
> 
> Code itself looks good.
> 
> My only concern is how hard it will be to find them -- one of the benefits of
> exposing them as separate events is that it is easy for someone to look in the
> net logs and see why their browser is 'making' so many connections to our DNS
> servers.

NetLog isn't really targeted at end users, or this use case.  And I'm not sure
all those extra events help.  We already show the UDP sockets for the probes as
top level events.

I just popped an about:net-internals, and opened the NTP...What do I see on the
first page of events:

3 SOCKETs (2 because I didn't flush the socket pools first)
2 SPDY_SESSIONS (2 because I didn't flush the socket pools first)
5 HTTP_STREAM_JOBS
9 IPV6_REACHABILITY_CHECKS
9 UDP_SOCKETs for those checks
3 CONNECT_JOBs (Admittedly, would be more, but the NTP talks to known SPDY
servers)
3 HOST_RESOLVER_IMPL_JOBs

So that's 34 events visible on the first page.  *18* of them are related solely
to those completely redundant probes.  When a net developer is digging through a
net log, how often do you think he cares about those?  You could also say other
things would be nice to know at the top level, too - like when we check the
AppCache, or when a request is idling due to a network delegate being evil.

I actually don't feel that strongly about it, but I do think all that extra top
level events makes it harder to figure out what's going on when there are a
bunch of related events.  If we were still caching probe results, I think top
level events make a lot of sense.  As-is, though...

[Deprecated (see juliatuttle), 2015-04-24 02:32:37]

lgtm.

[mmenke, 2015-04-24 15:01:33]

On 2015/04/24 02:32:37, ttuttle wrote:
> lgtm.

Thanks, completely forgot about this one.  :)

[mmenke, 2015-04-24 15:29:48]

Patchset #3 (id:60001) has been deleted

[mmenke, 2015-04-24 15:30:09]

The CQ bit was checked by mmenke@chromium.org

[mmenke, 2015-04-24 15:30:09]

The patchset sent to the CQ was uploaded after l-g-t-m from ttuttle@chromium.org
Link to the patchset: https://codereview.chromium.org/927533005/#ps80001 (title:
"Merge 2")

[commit-bot: I haz the power, 2015-04-24 15:31:00]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/927533005/80001

[mmenke, 2015-04-24 15:33:36]

The CQ bit was unchecked by mmenke@chromium.org

[mmenke, 2015-04-24 15:56:02]

The CQ bit was checked by mmenke@chromium.org

[mmenke, 2015-04-24 15:56:02]

The patchset sent to the CQ was uploaded after l-g-t-m from ttuttle@chromium.org
Link to the patchset: https://codereview.chromium.org/927533005/#ps100001
(title: "Fix merge bug")

[commit-bot: I haz the power, 2015-04-24 15:56:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/927533005/100001

[commit-bot: I haz the power, 2015-04-24 17:08:55]

Committed patchset #4 (id:100001)

[commit-bot: I haz the power, 2015-04-24 17:09:46]

Patchset 4 (id:??) landed as
https://crrev.com/04ffcf25e708f3835ad4a48af044b2fb10aa6c27
Cr-Commit-Position: refs/heads/master@{#326823}