Default Timeout for Push Operation
Patrick Downey
patd at symbian.org
Tue Feb 23 10:45:15 CST 2010
Hi Matt,
We were seeing a similar type of behaviour with some of our large
repositories on Apache, often from connections with high latency and
low bandwidth links.
I never worked out exactly what was going wrong but we worked around
the issue using a couple of approaches:
1. We removed a sometimes long running changegroup hook (i.e. hg
update -r tip) - we tried using the live repositories for our cross-
referencer and so needed this hook to keep the xref source code up to
date. That approach was fairly short lived.
2. We increased the Apache Timeout value
So while we never got to the bottom of what was going wrong, I believe
it was due to the length of time whereby nothing was being sent from
the server to the client while the server was updating it's workspace.
Do you have any potentially long running changegroup hooks that might
be causing the timeout? or (showing my IIS ignorance here) is there
another timeout variable that might help?
This solution seems to have worked for our large incoming deliveries
and also for some large hg clone/pull operations that were failing
over the bad links.
Good luck!
Pat
On 23 Feb 2010, at 15:26, Matt Hawley wrote:
> Hi Benoit,
>
> We are running Windows Server 2008 R2 in IIS 7.5, but with ASP.NET
> enabled and in integrated mode. The client, is also running on
> Windows Server 2008 R2, but we've also experienced the same effect
> on a Windows 7 x64 and Windows 7 x86 box connecting to the same
> repository for pushing. When looking at the server at this time,
> there is no activity in python.exe or w3wp.exe, as well as no
> network traffic (which I would assume would be there considering
> we're uploading 150MB).
>
> Please let me know what more you'd need in helping identify the root
> cause. We haven't had any users complain about this, but we'd rather
> not get to that point.
>
> Thanks,
> Matt
>
> -----Original Message-----
> From: Benoit Boissinot [mailto:benoit.boissinot at ens-lyon.org]
> Sent: Tuesday, February 23, 2010 2:14 AM
> To: Matt Hawley
> Cc: mercurial at selenic.com
> Subject: Re: Default Timeout for Push Operation
>
> On Mon, Feb 22, 2010 at 07:55:57PM +0000, Matt Hawley wrote:
>> Hi all,
>
> Hi Matt,
>>
>> I'm trying to figure out a problem with the CodePlex installation of
>> Mercurial in which we're trying to push a repository that is about
>> 150MB in size (or larger). We're running in IIS Integrated mode, and
>> have set the max upload size to be about 300MB. However, when trying
>> to push I get the following:
>
>
> I think that was reported on IRC too, but I don't remember the
> details (specifically, if the server was running IIS, or if it was
> Linux or similar).
>>
>>>> hg push -time -debug
>> using https://localhost:4431/Repo3
>> sending between command
>> pushing to https://localhost:4431/Repo3 sending capabilities command
>> capabilities: unbundle=HG10GZ,HG10BZ,HG10UN branchmap lookup
>> changegroupsubset sending heads command searching for changes common
>> changesets up to 0000000000000
>> 1 changesets found
>> List of changesets:
>> <ab71e...>
>> sending unbundle command
>> sending 138181097 bytes
>> abort: error: Connection reset by peer
>> Time: real 282.927 secs (user 2.761+0.000 sys 13.494+0.000)
>>
>> I turned on failed request tracing in IIS, and when looking through I
>> see a 2 min 10 sec gap, upon which it returns a message "The I/O
>> operation has been aborted because of either a thread exit or an
>> application request." Looking around, this generally means the client
>> disconnected from the server, and this is the error that IIS reports.
>
> Is this something specific to the OS run by the client? I don't see
> anything we do in hg itself that would change defaults OS values. So
> in my opinion, it's either python or OS related.
>
> If we know what's wrong, we can try to change it.
>
> Cheers,
>
> Benoit
>
>
> --
> :wq
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
More information about the Mercurial
mailing list