[Webkit-unassigned] [Bug 141508] New: [SOUP] Synchronous XMLHttpRequests can time out when we reach the max connections limit

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=141508

            Bug ID: 141508
           Summary: [SOUP] Synchronous XMLHttpRequests can time out when
                    we reach the max connections limit
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: Platform
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cgarcia at igalia.com
                CC: danw at gnome.org, gns at gnome.org, mrobinson at webkit.org,
                    svillar at igalia.com

This is the same problem that bug #84560 tried to fix, but nowadays the browser is not frozen, but the sync requests end up timing out after the 10 seconds timeout used by default for sync loads. The patch that landed in bug #84560 was not enough. This is what is happening now:

 1. We are the max connections limit (normally the connections per host).
 2. A new sync load is started, we increase the max conns limit by 1. Let's say max conns per host was 6, now is 7. We run the nested main loop with a custom context to ensure next request is the only one processed.
 3. The request is correctly processed creating the new connection needed, now current num connection wold be 7.
 4. The syn request finishes, so we finish the nested main loop and the limits are decreased by one again. The mac conns per host is now 6, but current num conns is still 7. At this point the connection is still IN_USE, because the message is still in the queue.
 5. A new sync request is started, we increase the limits again, now max conns per host would be 7 again
 6. The new load is not processed because current num conns is still 7 and limit is also 7. The new connection we created for the previous request hasn't been dropped.
 7. Nothing is processed, because the nested main loop and the connections limit, so we keep doing nothing for 10 seconds until the timeout source is scheduled.

And this keeps happening all the time while there are more sync loads. This not only makes many things not working, but everything very slow, since we do nothing for 10 seconds every time this happen.

The first solution that I thought was dropping idle connections in libsoup after the conns limits is set when the new limit is less than the current number of connections. But when we decrease the limits (in step 4) the message is still running, it switches to finishing right after step 4, so the connection is still in IN_USE state. After step 4, the message is processed again and it switches to FINISHED, then it's unqueued and its connection is set to IDLE.

We might try to keep that approach, but decreasing the limits in an idle, but I'm not sure if it would be possible that before the idle, the connection is reused by another request waiting for a connection free, and set to IN_USE again. If this approach would be possible, we could even cancel the idle if a new sync request is started immediately and reuse the connection. But i'm not sure this is possible or reliable.

Any other solution that I can think of, would require new libsoup API, something like a message flag (IGNORE_CONNECTION_LIMITS, for example), that forces the message to create a new connection but only if we have reached the limit (otherwise we would reuse an idle connection unless there's another message flag or whatever preventing that). If a new connection is created for this particular message, we would drop that connection automatically when the message is unqueued (again we could do that after a short delay, just in case another message with that flag is queued).

What do you think? any other solution?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150212/9ccfbaf4/attachment-0002.html>