On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote: > Mojca Miklavec writes: >> On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote: >>> Mojca Miklavec writes: >>> >>>> Yes, there is still a problem after restarting Apache. Even though it >>>> works for me at the moment and I tried fetching from multiple >>>> locations and servers, other users are still experiencing the same >>>> problem. Logs on the server confirm that. (Unable to deliver content. >>>> [500, #0] + Could not write data to filter. [500, #175002]) >>> >>> Does the server log always contain the error: >>> >>> svn: E160004: Corrupt node-revision '2-1.0.r137/330061' >> >> I don't see that in the server log, but I was only checking error.log >> written by Apache server, I don't know where else to look, but I can >> check if you point me in the right direction. This error is sometimes >> displayed by the "client" (either in XML in the browser or as an error >> in the command line during "svn up"), but it's not consistent and it >> often works properly. > > It would be in the Apache error log.
Ah, OK, I see it now in the old logs. There are no such lines in the latest logs. > Are you saying that sometimes the client gets the E175002 error without > the 'Corrupt node-revision' part? Yes. I'm attaching full log (with timestamps and IPs removed) for a certain period of time around 4th January. There are plenty of E175002 errors without any subsequent 'Corrupt node-revision' part, including all the latest entries (not part of the attachment). > Are you saying that the client gets the 'Corrupt node-revision' error > but it is not recorded in the error log? I was wrong about that. I was only checking the latest error log where all I get is [dav:error] [pid 42289] [<IP>:29011] Unable to deliver content. [500, #0] [dav:error] [pid 42289] [<IP>:29011] Could not write data to filter. [500, #175002] But I've found those additonal errors in an old (archived) log. At the moment I'm unable to reproduce the error 'Corrupt node-revision' both on the client and in server logs, but the repository is still misbehaving. >> It sometimes works in the first attempt, fails in the second one, and >> succeeds in the third attempt again. Only seconds or minutes apart. >> >>> Is it always '2-1.0.r137/330061'? >> >> The exact revision reported as currupt depends on which subfolder I'm >> checking out. I believe it reports the last commit when files in that >> particular subfolder were modified. (I've seen this error when >> checking out two different subfolders. The number was always the same >> for the same subfolder, but different for different subfolders.) >> >> (It is a bit difficult to test because the behaviour is not consistent.) > > Which version of Apache are you using? Which Apache MPM are you using? Server version: Apache/2.4.7 (Unix) I'm not sure how to check MPM. I get > httpd -l Compiled in modules: core.c mod_so.c http_core.c but "httpd -V" as suggested on some websites doesn't work. How should I check which MPM is being used? > What sort of filesystem is used for the repository? Is it a local disk > or a network disk? The repository is stored on a local disk. I'm not sure what about filesystem is it that you are asking, but here are some possibly relevant data: > cat format 5 > cat db/fs-type fsfs > cat db/format 6 layout sharded 1000 (and before I upgraded the repository, db/format was 4). Is that what you were asking or do did you want to know something else? Mojca
error.log
Description: Binary data