abort: stream ended unexpectedly when cloning repo

Eugene Lepekhin eugene.lepekhin at gmail.com
Wed Aug 10 01:13:14 UTC 2016


Ok, three months later I am able to get back to this problem.
I've tried this script and I am getting the logs. One of them just empty, I
guess the log file's buffer was not flashed before the script get
terminated.
In the IIS logs I don't see anything specific.
Here is the snap of the log:
10.0.32.194, -, 8/9/2016, 17:23:23, W3SVC1, ELVM1, 10.0.32.181, 299, 187,
494, 200, 0, GET, /hg/hgweb.cgi/OSN, cmd=capabilities,
10.0.32.194, -, 8/9/2016, 17:23:23, W3SVC1, ELVM1, 10.0.32.181, 233, 238,
205, 200, 0, GET, /hg/hgweb.cgi/OSN, cmd=batch,
10.0.32.194, -, 8/9/2016, 17:37:27, W3SVC1, ELVM1, 10.0.32.181, 844302,
597, 4294967457, 200, 0, GET, /hg/hgweb.cgi/OSN, cmd=getbundle,

even last line is returning code 200.

Any thoughts?
Thanks,
Eugene



On Thu, May 5, 2016 at 11:59 PM, Eugene Lepekhin <eugene.lepekhin at gmail.com>
wrote:

> Thanks Simon,
> I'll try to do this.
> Regards,
> Eugene
>
>
> On Thu, May 5, 2016 at 1:36 AM, Simon King <simon at simonking.org.uk> wrote:
>
>> You could try adding some logging to your hgweb.cgi file. If this were
>> Apache, I think you could write to sys.stderr and it would appear in
>> Apache's error log. I don't know anything about IIS though, so that might
>> not work. Instead, you could replace the "wsgicgi.launch(...)" line with
>> something like this (untested):
>>
>> # use a randomly named logfile so that simultaneous requests
>> # don't interfere with each other
>> import uuid
>> logname = r'E:\HgRepos\hgweb.%s.log' % uuid.uuid4()
>> with open(logname, 'a') as log:
>>     log.write('starting to handle request\n')
>>     try:
>>         wsgicgi.launch(application)
>>     except:
>>         import traceback
>>         log.write(traceback.format_exc() + '\n')
>>         raise
>>     log.write('finished handling request')
>>
>> Once you've done this, you should see a log file appear for each HTTP
>> request. Each log file should either finish with "finished handling
>> request" or a traceback. If you find a log file that doesn't have either,
>> it would suggest that the python interpreter is being killed uncleanly (in
>> which case you need to start investigating operating-system level logs)
>>
>> Hope that helps,
>>
>> Simon
>>
>> On Thu, May 5, 2016 at 8:20 AM, Eugene Lepekhin <
>> eugene.lepekhin at gmail.com> wrote:
>>
>>> Ok, that is really good to know, thanks. Can you please suggest on how
>>> do I do this? Uncommenting traceback line did not help as obviously there
>>> is no browser involve.
>>>
>>> On Wed, May 4, 2016 at 8:40 PM, Matt Mackall <mpm at selenic.com> wrote:
>>>
>>>> On Wed, 2016-05-04 at 17:05 -0700, Eugene Lepekhin wrote:
>>>> > Thanks Matt,
>>>> > I have tried to clone from hg serve and it works fine. I don't use
>>>> https,
>>>> > IIS timeout set to 1hour and the operation aborted after 15 minutes,
>>>> > its about 5 GB is free out of 8 GB total on the server. It is
>>>> happening
>>>> > always  from any client machine. Virus scan is disabled for the folder
>>>> > containing hg repos.
>>>> > Here is the output with trace back:
>>>>
>>>> Yes, this is STILL meaningless.
>>>>
>>>> > C:\Temp\sp>hg clone --verbose --traceback http://zmfs01/hg/SP/
>>>> "C:\Temp\sp"
>>>> > requesting all changes
>>>>
>>>> This is the last point at which the client communicates with the
>>>> server. The
>>>> server starts sending data. Minutes pass..
>>>>
>>>> > adding changesets
>>>> > adding manifests
>>>> > adding file changes
>>>> > transaction abort!
>>>>
>>>> At this point, after minutes of uneventful bulk transfer, the server
>>>> terminates
>>>> the connection without warning and without telling the client why. The
>>>> client
>>>> begins cleaning up the mess.
>>>>
>>>> > rollback completed
>>>>
>>>> The mess is cleaned up.
>>>>
>>>> > Abort: stream ended unexpectedly (got 0 bytes, expected 4)
>>>> > abort: stream ended unexpectedly (got 0 bytes, expected 4)
>>>>
>>>> And here it says why: server hung up. How rude.
>>>>
>>>> No amount of staring at this client-side output is going to tell us why
>>>> the
>>>> server decided to hang up. We need the traceback or exception =on the
>>>> server
>>>> side=.
>>>>
>>>> --
>>>> Mathematics is the supreme nostalgia of our time.
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mercurial mailing list
>>> Mercurial at mercurial-scm.org
>>> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial/attachments/20160809/50332d41/attachment.html>


More information about the Mercurial mailing list