Delta source ended unexpectedly [500, #200003] using Subversion 1.6.17 with Apache http server 2.2.21
Hello community, I have compiled subversion 1.6.17 and Apache 2.2.21 from source on CentOS 5.6 and serving my repository using Apache httpd server with the following details : Server version: Apache/2.2.21 (Unix) Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Getting the folloiwng normal message in apache log : [Sat Feb 11 14:13:41 2012] [notice] Apache/2.2.21 (Unix) DAV/2 mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 SVN/1.6.17 PHP/5.1.6 configured -- resuming normal operations Problem : When try to commit from the checkout made from master everything works fine, but when I try to commit from the checkout from slave I get the following message in apache's log : [Sat Feb 11 10:04:01 2012] [error] [client xxx.xxx.xx.xxx] could not write the file contents [500, #23] [Sat Feb 11 10:04:01 2012] [error] [client xxx.xxx.xx.xxx] Delta source ended unexpectedly [500, #23] I am using TortoiseSVN 1.6.16 to commit to repository. Does somebody knows if this is known bug or have somebody faced this issue earlier? Thanks for the help in advance! Regards Ravi.
Re: Delta source ended unexpectedly [500, #200003] using Subversion 1.6.17 with Apache http server 2.2.21
I found this under http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=193527 in the mail archive of dated back to 2002 and this seems to be fixed as per the bug report. Can somebody please comment on the issue? Thanks. On Sat, Feb 11, 2012 at 2:40 PM, Ravi Roy wrote: > Hello community, > > I have compiled subversion 1.6.17 and Apache 2.2.21 from source on CentOS > 5.6 and serving my repository using Apache httpd server with the following > details : > > Server version: Apache/2.2.21 (Unix) > Server loaded: APR 1.4.5, APR-Util 1.3.12 > Compiled using: APR 1.4.5, APR-Util 1.3.12 > > Getting the folloiwng normal message in apache log : > > [Sat Feb 11 14:13:41 2012] [notice] Apache/2.2.21 (Unix) DAV/2 > mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 SVN/1.6.17 PHP/5.1.6 configured -- > resuming normal operations > > Problem : When try to commit from the checkout made from master everything > works fine, but when I try to commit from the checkout from slave I get the > following message in apache's log : > > [Sat Feb 11 10:04:01 2012] [error] [client xxx.xxx.xx.xxx] could not write > the file contents [500, #23] > [Sat Feb 11 10:04:01 2012] [error] [client xxx.xxx.xx.xxx] Delta source > ended unexpectedly [500, #23] > > I am using TortoiseSVN 1.6.16 to commit to repository. > > Does somebody knows if this is known bug or have somebody faced this issue > earlier? > > Thanks for the help in advance! > > Regards > Ravi. >
Re: Delta source ended unexpectedly [500, #200003] using Subversion 1.6.17 with Apache http server 2.2.21
On Sat, Feb 11, 2012 at 04:36:46PM +0530, Ravi Roy wrote: > I found this under > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=193527 > in the mail archive of dated back to 2002 and this seems to be fixed as per > the bug report. > > Can somebody please comment on the issue? So you're running a master/slave setup with a write-through proxy configuration, yes? You don't mention whether you're quoting logs from the master or from the slave server. Is the slave repository properly synced with the master? Does 'svnadmin verify' pass on both sides or is there repository corruption involved? Could this problem be relevant? http://subversion.tigris.org/issues/show_bug.cgi?id=3445 > On Sat, Feb 11, 2012 at 2:40 PM, Ravi Roy wrote: > > > Hello community, > > > > I have compiled subversion 1.6.17 and Apache 2.2.21 from source on CentOS > > 5.6 and serving my repository using Apache httpd server with the following > > details : > > > > Server version: Apache/2.2.21 (Unix) > > Server loaded: APR 1.4.5, APR-Util 1.3.12 > > Compiled using: APR 1.4.5, APR-Util 1.3.12 > > > > Getting the folloiwng normal message in apache log : > > > > [Sat Feb 11 14:13:41 2012] [notice] Apache/2.2.21 (Unix) DAV/2 > > mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 SVN/1.6.17 PHP/5.1.6 configured -- > > resuming normal operations > > > > Problem : When try to commit from the checkout made from master everything > > works fine, but when I try to commit from the checkout from slave I get the > > following message in apache's log : > > > > [Sat Feb 11 10:04:01 2012] [error] [client xxx.xxx.xx.xxx] could not write > > the file contents [500, #23] > > [Sat Feb 11 10:04:01 2012] [error] [client xxx.xxx.xx.xxx] Delta source > > ended unexpectedly [500, #23] > > > > I am using TortoiseSVN 1.6.16 to commit to repository. > > > > Does somebody knows if this is known bug or have somebody faced this issue > > earlier? > > > > Thanks for the help in advance! > > > > Regards > > Ravi. > >
Re: Delta source ended unexpectedly [500, #200003] using Subversion 1.6.17 with Apache http server 2.2.21
> So you're running a master/slave setup with a write-through proxy > configuration, yes? You don't mention whether you're quoting logs > from the master or from the slave server. > I apologize; yes I am running master/slave setup with a write-trough proxy. Logs belong to Master. > > Is the slave repository properly synced with the master? > Before trying to commit, both master and slave are synced. > > Does 'svnadmin verify' pass on both sides or is there repository > corruption involved? > I used 'svnadmin verify' and all revisions are verified and no error / inconsistency reported. > > Could this problem be relevant? > http://subversion.tigris.org/issues/show_bug.cgi?id=3445 > Could be, but I have to verify it. Thanks!
Re: multiple svn front-ends, single SAN repo volume
The current storage isn't on the SAN, so yes, we believe the new storage will be faster. It's already many repositories, not a single one, so we're already in good shape there. -- Bruce Z. Lysik From: Les Mikesell To: Bruce Lysik Cc: "users@subversion.apache.org" Sent: Friday, February 10, 2012 10:50 PM Subject: Re: multiple svn front-ends, single SAN repo volume On Fri, Feb 10, 2012 at 11:29 PM, Bruce Lysik wrote: > We have a single server installation which is currently not fast enough. > > The LB pair + 3 svn front-ends + SAN storage is not strictly for > performance, but also for reliability. Scaling vertically would probably > solve performance problems in the short term, but still wouldn't address > single points of failure. > > Thanks for all the responses to this thread, it's very educational. Is the current storage on the san? If not, putting it there with fail-over svn servers fixes the reliability issue without introducing new locking issues. And if the san is faster than the local disk it may help with speed as well. Does it all have to be in a single repository? If not, moving different parts to different svn servers spreads the load without sharing the same transaction lock. -- Les Mikesell lesmikes...@gmail.com
Re: multiple svn front-ends, single SAN repo volume
On Fri, Feb 10, 2012 at 6:14 PM, Stefan Sperling wrote: > On Fri, Feb 10, 2012 at 04:47:31PM -0600, Ryan Schmidt wrote: >> So thinking all this through, I agree svnsync does not make sense if >> you are hosting a repository on a SAN and trying to connect multiple >> svn servers to it. But it sounds like it would work fine, if you >> simply don't use svnsync. Configure one server to be the master (let >> it accept write requests). Configure the other servers to be slaves >> (read-only, and proxy any incoming write requests to the master). All >> servers point to the same repository data on the SAN and it can't get >> corrupted because only one server is writing to it. Sound ok? > > Ah, I see what you mean. > > Well, I suppose this would work, yes. You are essentially using > the write-through proxy feature to implement load balancing for > incoming TCP connections. > > But it isn't necessary because the SAN should support file locking > so multiple concurrent servers writing to the same repository > synchronise write operations anyway. I would be *extremely* leery of this kind of multiple simultaneous write access to a shared resource. Even with a SAN, filesystem changes on one system are vulnerable to phase delays or interruptions, and there have been way, way, way too many systems that worked very well this way until stressed and corrupted the heck out of what were supposed to be atomic corruptions. The ability of filesystem authors to change specs and practics and update parameters, and create really startling changes in systems that used to work well, is amazing. If what you're running into is performance issues, I'm really going to urge you to talk to Wandisco about their distributed multi-server setup, which seems to to a very good job of doing synchronized, distributed servers.
Re: multiple svn front-ends, single SAN repo volume
On Sat, Feb 11, 2012 at 5:36 PM, Nico Kadel-Garcia wrote: > I would be *extremely* leery of this kind of multiple simultaneous > write access to a shared resource. Even with a SAN, filesystem changes > on one system are vulnerable to phase delays or interruptions, and > there have been way, way, way too many systems that worked very well > this way until stressed and corrupted the heck out of what were > supposed to be atomic corruptions. The ability of filesystem authors > to change specs and practics and update parameters, and create really > startling changes in systems that used to work well, is amazing. By the way: I'm not making this claim based on reading the Subversion handling of atomic operations, but rather on several decades of experience of exciting surprises in filesystem adventures.
svnserve daemon mode + SSH
Hi list, can I use svnserve in daemon mode (to take advantage of its authorization mechanisms) and still have the client use an SSH tunnel (probably with different credentials) to connect to it, so I only have to expose the SSH port? I found a post at http://svn.haxx.se/users/archive-2004-12/1413.shtml talking about something called "SVN over SSH" but it's not mentioning how to set it up. Regards, André
Re: svnserve daemon mode + SSH
You should look into either svn+ssh:// or using svnserve over ssh port
forwarding ('ssh -L'). These are two distinct options. The former is
documented in the book; some of the SSH set-up tips there are applicable
to both modes.
André Hänsel wrote on Sun, Feb 12, 2012 at 03:27:12 +0100:
> Hi list,
>
> can I use svnserve in daemon mode (to take advantage of its authorization
> mechanisms) and still have the client use an SSH tunnel (probably with
> different credentials) to connect to it, so I only have to expose the SSH
> port?
>
> I found a post at http://svn.haxx.se/users/archive-2004-12/1413.shtml
> talking about something called "SVN over SSH" but it's not mentioning how to
> set it up.
>
> Regards,
> André
>
Re: svnserve daemon mode + SSH
On Sat, Feb 11, 2012 at 9:27 PM, André Hänsel wrote: > Hi list, > > can I use svnserve in daemon mode (to take advantage of its authorization > mechanisms) and still have the client use an SSH tunnel (probably with > different credentials) to connect to it, so I only have to expose the SSH > port? > > I found a post at http://svn.haxx.se/users/archive-2004-12/1413.shtml > talking about something called "SVN over SSH" but it's not mentioning how to > set it up. It's in the famous Subversion "Red Book", at http://svnbook.red-bean.com/. It works well: the only difficulty with it is managing the keys, which needs to be worked out thoughtfully as a matter of policy file management. The last example, the one that uses individual keys installed in an svn user account, forced commands, specific usernames tied to the keys with, and perhaps even the "--root" directove to provide simpler URL's is the one you want to use. I've been a strong proponent of it for years because it avoids Linux and UNIX clients for Subversion storing passwords in cleartext, as all such clients do by default for HTTP and HTTPS access. It also can avoid fascinating interactions with Apache setups. There are performance and configuration trade-offs, but I find it very usefl, especially if I need to publish a freely accessible version of the repository that can be just plain "http" accessed. This is how www.sourceforge.net does this.
Finally got around to putting subversion-1.7.2 RPM building components at https://github.com/nkadel/subversion-1.7.2-srpm
I finally got around to putting these up on github.com. I've submitted these to repoforge, and will submit them to Fedora. These are the bits and pieces necessary to build clean RPM's for RHEL 5, RHEL 6, and recent Fedora releases of subversion-1.7.2. The irony of publishing Subversion patches on a git repository is not lost on me. There are also some subtleties in the .spec file: The dependencies for KDE have changing names between releases of RHEL, and don't work in older releases, so the .spec file does not enable them for older releases. The previously included "psvn" tools are still in the RPM's, even though they're no longer in a "contrib" directory of Subversion source code. The psvn tools are also *not* installed on older RHEL releases, becauase the compatibility with Emacs has changed and they requie a recent emacs. But rather than factor that out separately and get incompatible with expected Fedora layouts, I just excluded it or not as appropriate, because it *breaks* Emacs rather badly if Emacs is not recent enough. "serf" or "libserf" is not part of RHEL or Fedora, so serf support is not yet enabled. If it's desirable, I've got a structure for replacing the old RPM building widgets in the Subversion source tree. It basically runs "make" against a subversion.spec.in, and applies the above patches. I can put that up as well if there's any desire to use that for testing. The old existing structure replaces the user's ".rpmmacros" file, without warning, which I personally consider quite nasty.
Re: Delta source ended unexpectedly [500, #200003] using Subversion 1.6.17 with Apache http server 2.2.21
On Sun, Feb 12, 2012 at 4:18 AM, Nico Kadel-Garcia wrote: > On Sat, Feb 11, 2012 at 4:10 AM, Ravi Roy wrote: > > Hello community, > > > > I have compiled subversion 1.6.17 and Apache 2.2.21 from source on CentOS > > 5.6 and serving my repository using Apache httpd server with the > following > > details : > > If you need the latest Subversion features, consider hopping directly > to the 1.7.1 or pending 1.7.2 release for RPMforge. My .spec files are > at https://github.com/nkadel/subversion-1.7.2-srpm: Enjoy. > This is a decision which is not easy to take :-) Thanks. > > Why are you using CentOS 5.x to support such a large update as Apache > 2.2.21? Wouldn't you be better off updateing to CentOS or Scientific > Linux 6.x and using httpd-2.2.15 ? > Did not know about this (large update ..etc). I updated to httpd-2.2.15 but problems were not resolved. But when I downgraded to Subversion 1.6.12 alongwith httpd-2.2.15, problems are resolved. May be somebody needs to analyze as to why Subversion 1.6.17 have got these problems... Thanks everyone for help and support.
Re: multiple svn front-ends, single SAN repo volume
On 2/10/2012 10:21 AM, Bruce Lysik wrote: Hi, I'm considering deploying 3 front-ends, all mounting the same SAN volume for repo. (The SAN handle flock() and fnctl() correctly.) These 3 FEs would be load balanced by a Citrix Netscaler. (At least for http(s).) The largest issues I've run into using a shared storage is not the flock() and fcntl() but the atomic renames. fsfs will atomically rename three files to do a commit and the last rename of the 'current' file, on some shared filesystems, will result in points of time where the systems not doing a commit will not see a 'current' file. If this happens, then any svn read or write operation on the repository will temporarily fail. We had GPFS and it never failed to implement the posix requirements, but it was slow for the number of commits we were pushing (6/sec), so we ended up going to a single server solution with a standby. There was another filesystem, I forgot its name, which didn't implement atomic renames correctly and wasn't usable for svn. Have you tested your SAN deployment? What I would do is create a fsfs repository and on one of your hosts, do as many commits per second as you can in a tight loop, then have another host in a tight loop do an operation on the repository, like get the log message of the HEAD revision. If you want to test your flock() and fcntl() and see how well that performs, try to do as many commits per second into the same repo from two or more hosts. In this case, have a repository with N directories and have each host modify a file in a single directory, that way you won't get any conflicts. How many commits per second are you expecting in practice? Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/
