D1568: lfs: using workers in lfs prefetch

mharbison72 (Matt Harbison) phabricator at mercurial-scm.org
Wed Jan 3 23:29:52 UTC 2018


mharbison72 added a comment.


  I'm seeing some corruption that appears to be related to workers, so maybe we should default the lfs workers to 'disabled'?
  
  The setup is the latest default + some convert extension hacking pushing between local repos on CentOS 7.4.  The lfs host is `gitbucket` on another server running CentOS 7.4.  There are 36 blobs to transfer, totaling 348MB.  It prints out a bunch of "uploading" and "processed" messages, but then grinds to a halt, and eventually prints a "500: Internal Server Error" after a couple minutes.  I added more logging, including printing out the httperror data, which ends up being a socket timeout exception.  The server side is only getting part of some files.  Typically it is one or two of the first files to be sent that end up being truncated.  Since they are ~2MB C files, I can diff and see that it is the beginning of the file that is missing (different amounts each time).  I also added code to filewithprogress.read() to tally up the length of the data read, and it is the expected size every time `fp.read()` returns None.
  
  Setting `worker.enabled = False` seems to avoid the problem, and it can be reproduced on demand by toggling it back on.  When trying to get a wireshark trace, I also noticed that changing `lfs.url` to http instead of https also seems to avoid the problem.  (The response URLs for where to send the blobs were still all https, so I couldn't watch those.  A coworker changed some config to try to make them http, and now a 400 is being returned, so I'm going to have him put it back.)
  
  So this may not be a Mercurial problem.  But I thought there were initial concerns about using workers safely, so I thought I'd report back and see if there were any ideas.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1568

To: wlis, #hg-reviewers, quark, mharbison72
Cc: mharbison72, quark, mercurial-devel


More information about the Mercurial-devel mailing list