On Thursday, December 03, 2015 5:21 AM, Andy Bradford wrote:
Thus said Andy Gibbs on Wed, 02 Dec 2015 16:56:35 +0100:
I can certainly let you know when (if?) it happens again. What can I
say about my usage patterns? ... I am certainly doing large check-ins,
for example, modifying 100s of files at once.
That certainly is similar to the criteria for the previous conditions.
Before the previous fix I had reproduced it with 1,500 changed files in
a single commit, thus resulting in a manifest with a lot of F-cards.
I saw in the referenced threads that max-download also had something to
do with it:
http://marc.info/?l=fossil-users&m=144565833040818&w=2
I had a look at the description for max-download (download packet limit)
and I'm not sure. The limit is 5MB (M not Mi!) by default it would seem.
What I'm not sure about is what this limit exactly applies to - from the
description given (I haven't looked in the source code) - i.e. I am pretty
sure an individual check-in could easily exceed 5MB of uncompressed diffs
for example. Worst case, a single file could have 5MB of changes (or be
a new 5MB+ file). I can check further and get concrete numbers if this
would help, but I'm assuming this shouldn't be a factor.
For reference, a single commit may lead to around 100 "round-trips" to
then sync with the server (assuming no commits coming back as well).
Though I'm not sure that is actually a requirement for reproducing the
problem. At any rate, I had default values for max-download.
One thing you can do on the server is run:
fossil test-clusters /path/to/project.fossil
Ok, this produced a very long list starting thusly:
170716 unreachable artifacts:
127299 000017df491816cdbd40fcbca031950decdf9532
150554 000067ad9657662b33a669d87934b6df91a62f71
134125 000091fa0dc5528c0595b16c4cc56f9365bfbba0
68008 0000cc81620bd3ff86379b744e4dae91df8f6175
121858 00018c2a5a32810f19ee140a12eaa9e32bec06cd
99123 00022cc63cd3dabb4fcfc62a501994f785c2327d
[...]
Should I be worried?!
Do you have multiple servers to which clients synchronize content before
it makes it back to the server where you noticed the problem? Or any
other synchronization that happens between peers before making it into
the server where you noticed the problem? If so, are all the servers in
between 1.30 or newer?
Only one server, but about 15 clones spread across development machines
and buildbots. I don't know if this helps, but the buildbots sync (i.e.
really just pull, but use the sync command) fairly regularly and should
generally sync at the same points in the tree. What I notice is that I've
only ever had the issue once on one (maybe two) buildbots, but possibly
long enough ago that I was using pre-1.30 software then. Generally the
buildbots are fine. The development machines are where the problem more
often occurs and it seems to happen more often when there is a number of
check-ins on the server to be replicated in the clone. I don't remember
it happening as part of a sync after a commit, but this could simply be
because a repository is synced and checked in the ui *before* doing any
major work and so any problems would already be apparent.
I am sorry this is awfully vague - it honestly doesn't happen enough that
I have a clear memory of all the details! I hope it helps though.
Cheers
Andy
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
