Bug 30661

Summary: Chromium HTTP Connection Count erroneously throttled to 4.
Product: WebKit Reporter: Mike Belshe <mbelshe>
Component: WebCore Misc.Assignee: Mike Belshe <mbelshe>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Other   
Attachments:
Description Flags
patch
fishd: review-
Patch 2; this time with the chromium implementation.
none
Patch 3 none

Description Mike Belshe 2009-10-21 22:08:18 PDT
When initializeMaximumHTTPConnectionCountPerHost() was introduced (ResourceRequestBase.cpp), it artificially throttled non-MAC platforms at 4 connections.

Chromium needs to use 6.
Comment 1 Mike Belshe 2009-10-22 00:20:13 PDT
Created attachment 41641 [details]
patch

Simple patch to do the same thing that the mac platform does - have this function be controlled outside of webkit.

A corresponding change will be made in the chromium api to provide this function.
Comment 2 Darin Fisher (:fishd, Google) 2009-10-22 06:28:36 PDT
Comment on attachment 41641 [details]
patch

> Index: WebCore/ChangeLog
...
> +        Make the number of connections for chromium controlled by
> +	chromium rather than by ReosurceRequestBase.
> +	https://bugs.webkit.org/show_bug.cgi?id=30661

nit: ^^^ remove the tabs


> Index: WebCore/platform/network/ResourceRequestBase.cpp
...
> +#if !PLATFORM(MAC) && !USE(CFNETWORK) && !USE(SOUP) && !PLATFORM(CHROMIUM)
>  unsigned initializeMaximumHTTPConnectionCountPerHost()

This method should probably be implemented in chromium/ResourceRequest.h as
either defined to return 6 or defined in terms of a ChromiumBridge function
call of exactly the same signature.
Comment 3 Mike Belshe 2009-10-22 09:09:56 PDT
Created attachment 41661 [details]
Patch 2; this time with the chromium implementation.
Comment 4 Eric Seidel (no email) 2009-10-22 10:45:45 PDT
Comment on attachment 41661 [details]
Patch 2; this time with the chromium implementation.

 9         No new tests. (OOPS!)
will have to be removed before commit.  Our documentation isn't very good on that subject, but the OOPS will cause the commit to fail.

Better would be to replace that with a short comment explaining why this is untestable (it actually probably isn't untestable, but could be kinda tricky).
Comment 5 Mike Belshe 2009-10-22 11:58:37 PDT
Created attachment 41674 [details]
Patch 3
Comment 6 WebKit Commit Bot 2009-10-24 17:33:47 PDT
Comment on attachment 41674 [details]
Patch 3

Rejecting patch 41674 from commit-queue.

mike@belshe.com does not have committer permissions according to http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/modules/committers.py.
Comment 7 Eric Seidel (no email) 2009-10-26 11:28:36 PDT
Comment on attachment 41674 [details]
Patch 3

I can't remember who is and who is not a committer these days.  But if you're a committer mike, feel free to add yourself to that file!  Otherwise you can set commit-queue? and someone will come along and cq+ your patches.

cq+ing this one now.
Comment 8 WebKit Commit Bot 2009-10-26 11:40:54 PDT
Comment on attachment 41674 [details]
Patch 3

Clearing flags on attachment: 41674

Committed r50079: <http://trac.webkit.org/changeset/50079>
Comment 9 WebKit Commit Bot 2009-10-26 11:40:58 PDT
All reviewed patches have been landed.  Closing bug.