183122 - Conn: should automatically retry stalled connections after X seconds of no data

Status: RESOLVED WORKSFORME

(Core :: Networking, enhancement)

Description

[JoSH Lehan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016

Sometimes, a TCP connection will stall: it will still be open, but no data will
transfer.  This is unfortunately common when using flaky servers or proxies that
"forget" about open connections.  If the user makes a new connection, it will
connect normally and complete correctly, but the existing stalled connection
will still be stalled.  Mozilla just sits there and waits forever for the
stalled connection to finish.

It would be much better if Mozilla could detect that no new data has arrived on
a given TCP connection after a user-configurable number of seconds.  When this
happened, Mozilla could abandon the connection and retry the same request again
on a new connection.  This action would be similar to hitting "Reload", except
that existing data (if any) would be preserved.  HTTP byte-range requests, and
the like, could be used to seamlessly resume the transfer.

I propose adding a choice in Preferences like this:

[X] Automatically retry stalled connections after ______ seconds

To be friendly to the network, a minimum value would be enforced here, perhaps
15 or 30 seconds.  Also, to keep things sane in the event of a server shutdown
or other permanent problem, there would need to be an absolute limit on the
number of retries that would be automatically performed.


Reproducible: Always

Steps to Reproduce:
1. Begin loading any web page that takes a long time to load.
2. Reproduce a failure in the network (perhaps by unplugging a network cable).
3. Observe that Mozilla simply waits forever on the existing connection, and
does not automatically retry.

Actual Results:  
Mozilla simply waits forever on the existing connection.

Expected Results:  
Mozilla should automatically abandon the current TCP connection and reconnect,
after no data has arrived on a connection for X seconds (user-configurable).

Comment 1

[benc]

+clean-report: good idea. A status message "retrying connection" would be nice too.

Comment 2

[Daniel Kabs, reporting bugs since 2002]

Arguing agains "clean report": Clean report requires the bug been reproduced by
someone other than the reporter and a valid testcase. I see neither of them.

To any sufficiently empowered user, please remove "clean report"! I am to small
a user to do that.

Comment 3

[benc]

->defaults.

Daniel: I'm the default QA for the component, and this seems like a reasonable
RFE. "clean-report" is also sort of a dead keyword now that we changed the
module owner model to having a few strong hackers (vs. the coder-by-reorg model
when Netscape paide a lot of people to own bugs they would never have time to fix.)

Comment 4

[Daniel Kabs, reporting bugs since 2002]

Thanks for the explanation, Benjamin. I complained because I wanted to make sure
that "newbies" only see nice reports when searching for this keyword. But it's
probably superseded by BugAThon[*] anyway. Or maybe I just envied not getting a
clean-report on my bug reports :-)

Cheers
Daniel

[*] http://www.mozilla.org/newlayout/bugathon.html

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Adam Hauner]

Confirming based on comments of benc.

Comment 7

[JoSH Lehan]

I'm glad to see an automated reaper system (like experts-exchange.com) for
dealing with dormant bug reports.

I originally filed this bug, and yes, it still happens in the latest beta.  Just
observed this the other day when trying to download something from a slow server
overseas.

There's a good number of plugins now to rearrange how and where the download
manager appears, but none to my knowledge actually have the power to affect how
downloads occur.  It's probably a low level change that needs to be made to the
file transfer code.  If I knew how to do it, I would :)

Comment 8

[Patrick McManus [:mcmanus]]

we have a series of timers and reapers these days.