Default Timeout for Push Operation

[Matt Hawley]

Hi Benoit,

I was able to successfully push changes under Linux, so it does look to be an Mercurial client + OS problem. When I was pushing under Windows, I was watching the network traffic, and it stopped uploading about 1/3 of the 150MB changes prior to prompting for authentication. Please let me know what else you would like to track this bug down. 

Matt

-----Original Message-----
From: Benoit Boissinot [mailto:benoit.boissinot at ens-lyon.org] 
Sent: Tuesday, February 23, 2010 10:27 AM
To: Matt Hawley
Cc: Patrick Downey; mercurial at selenic.com
Subject: Re: Default Timeout for Push Operation

On Tue, Feb 23, 2010 at 06:15:46PM +0000, Matt Hawley wrote:
> Hi Benoit,
> 
> Out of curiosity, I tried pushing without SSL, and things worked. I 
> re-tried under SSL and the same behavior occurred. Unfortunately, this 
> isn't a solution, as we need to have SSL enabled.

Ok. I would be really nice if you could see if it's an issue under linux, see if it's a problem with python's ssl support on windows or if it's more general.
> 
> Regarding wireshark - I've never used it and got a little overwhelmed 
> by what I need to do. Any guidance? Also, I've never ran with 
> --debugger, so if you could point me to some info on that, it would be 
> helpful.

For wireshark, I'm sorry I've never used it under windows. But the idea is to select a network interface, add a filter to restrict to some ports (you probably don't want to record all the traffic, only the traffic from hg to the server), that should be "port https" in the filtering box.


For --debugger, type 'continue' in the pdb shell (the debugging shell), then when you think it's stuck, kill the process (that's ctrl-c under unix, there should be something similar for windows).

You should be dropped into the pdb shell instead of just exiting, then type 'bt' to get a backtrace.

(thinking about it, if you just want a backtrace, just launch hg with --traceback, when it's killed it will print the full trackeback)

Another tool that could be useful if you find the windows equivalent is strace, this allows you to list the syscall() and return code of
syscall() made by the applications. With that you could see if it is waiting on a socket or something.


I hope this helps.

regards,

Benoit


--
:wq