Tested the issue in Android and could reproduce the issue. Observed the file_xx.js not loaded' messages on second navigation.

Steps Followed:
1. Launched Chrome .
2. Navigated to http://www.many-js.cba.pl/chrome_js_bug/
3. Navigated to Google.com
4. Navigated back to http://www.many-js.cba.pl/chrome_js_bug/
5. Observed the file_xx.js not loaded' messages on second navigation.


Chrome versions tested:
63.0.3239.111

OS
Android 7.0.0

Android Devices
Samsung J7

Considering this issue as Non-Regression issue as observing same behavior since M58.

Please navigate to below link for log's --
go/chrome-androidlogs/798977

Thanks!!

We limit the amount of memory we allow each renderer to allocate in the browser process when making network requests.  It like the script is making ~200 simultaneous requests.  The headers don't appear in the log, but lots of headers do increase the speed with which the limit is hit.  So I think that this is expected behavior, from the network side.  The limit is 25 MB of memory of outstanding requests per renderer.  According to a comment, this typically allows for ~6,000 requests, but if you have ~100k of headers per request, for whatever reason....

Thank you for response!

Scripts themselves do not make any requests. All network traffic is result of downloading resources by browser.
Therefore headers should be typical size, as sent by typical web server.

Let me explain structure of the website:

index.html contains 200 tags <script src="static/file_xxx.js"></script> and 200 div tags <div>file_xxx.js not loaded</div>. 

Each of file_xxx.js contains only one line of javascript code, which hides appropriate div, just for purpose of showing which files do not load.
Rest of each file are just comments, which make files larger.

Also, after I disabled cache in developer tools, everything seems to run fine.

Looks like I was wrong - we've actually read the response headers of the response from the cache, and get ERR_INSUFFICIENT_RESOURCES just before reading the body.  Moreover, it's logged with a CANCELLED event, and the only place that can happen looks to be in URLRequest::OnCancel, which means this is an error being sent to the network stack, not an error originating from it (i.e., we aren't running out of file handles at the cache layer or something).

The most likely culprit looks to be MojoAsyncResourceHandler, which tries to allocate a Mojo buffer before reading the response body to it.

[+yhirano]:  Does this sound plausible?

According to #2 the behavior is observed with M58 on which MojoAsyncResourceHandler is not enabled.

It's also possible that ResourceDispatcherHostImpl::HasSufficientResourcesForRequest returns false.

yhirano:  You're right.  Looks like that limits total started requests based on the fd limit.  May be best to start by separating the errors, and figure out which it is.  If it's the fd limit, seems like the logical option would be to just delay requests based on that, instead of cancelling them...  Though as we're actively working on replacing rdh, may be best to try and figure out how major this issue is, before taking any action, unless the issue is the Mojo calls failing.

Going to punt on this - RDH's days are limited, and only one report.