abort: stream ended unexpectedly when cloning repo

[Simon King]

I don't know what all the fields in those logs represent, but if the
10th field is the size of the response, then 4294967457 is 161 bytes
bigger than 4GB, which sounds very suspicious - perhaps you are
hitting a size limit somewhere?

You could try cloning just part of the repository's history using the
"-r" flag to "hg clone", then using "hg pull -r" in incremental steps
to get the rest.

It might also be interesting to try "hg clone --uncompressed"; I think
that streams the data off the disk instead of creating a bundle.

Simon

On Wed, Aug 10, 2016 at 2:13 AM, Eugene Lepekhin
<eugene.lepekhin at gmail.com> wrote:
> 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
>>>>
>>>
>>
>