Possible Bug Master/Slave repository with a 502 Bad Gateway. Not a HTTP/HTTPS translation problem
From: Jonathan Mark Petrush <jonpetrush_at_petrush.com>
Date: Wed, 18 Mar 2009 19:30:40 -0700 (PDT)
The following are the specifications of the error:
SERVER1 Master SVN Server compiled using subversion_1.5.6/apache_2.22.11/ruby_1.9.1p0/neon_0.28.3/apr_1.3.3/apr-iconv_1.2.1/apr-util_1.3.4/db_4.7.25/gsasl_0.2.29/jdk_1.6.012
configured and built through:
./configure --prefix=/opt/lampp --with-apr=/usr --with-apr-util=/usr --with-apxs=/opt/lampp/bin/apxs --with-zlib=/usr/lib --enable-experimental-libtool --with-jdk=/usr/src/jdk1.6.0_12 --with-ssl --with-sasl=/usr --with-berkeley-db=/usr/local/BerkeleyDB.4.7
compiler: GCC 4.1.2
Access through dav_svn through apache
Operating System: Slackware 12.2
including modules (of question)
LoadModule dav_module modules/mod_dav.so
SERVER2 Slave SVN Server compiled using subversion_1.5.6/apache_2.22.11/ruby_1.9.1p0/neon_0.28.3/apr_1.3.3/apr-iconv_1.2.1/apr-util_1.3.4/db_4.7.25/gsasl_0.2.29/jdk_1.6.012
configured and built through:
./configure --prefix=/opt/lampp --with-apr=/usr --with-apr-util=/usr --with-apxs=/opt/lampp/bin/apxs --with-zlib=/usr/lib --enable-experimental-libtool --with-jdk=/usr/src/jdk1.6.0_12 --with-ssl --with-sasl=/usr --with-berkeley-db=/usr/local/BerkeleyDB.4.7
compiler: GCC 4.1.2
Access through dav_svn through apache
Operating System: Slackware 12.0
<Location /ivr>
including modules (of question)
LoadModule dav_module modules/mod_dav.so
/////////////////////////////////////
The repositories were set up at fsfs type.
It should be noted that no issue exists if a commit is made directly to the master server, only errors occur when a commit is made to a slave repository which forwards to the master server. I have found a keyword that causes the commit to comeback with a 502 Gateway error.
Scenario and it can be reproduced and test on your own to verify that this is the case:
Set up a master repository.
Now create a new working directory.
It will commit properly
insert into the file the following:
FAILED: You will get a:
Transmitting file data .svn: Commit failed (details follow):
Now modify the file by putting letters in front of and behind the /bin/kill
FAILED: You will still get a:
Transmitting file data .svn: Commit failed (details follow):
now modify the file again one last time by altering the spelling of kill ie:
Success. Notice it commit properly.
[Wed Mar 18 22:02:59 2009] [error] [client xxx.xxx.xxx.xxx] (104)Connection reset by peer: proxy: error reading status line from remote server masterrepo
[Wed Mar 18 22:02:59 2009] [error] [client xxx.xxx.xxx.xxx] proxy: Error reading from remote server returned by /ivr/!svn/wrk/b2fd0c12-ff99-b94c-8718-107905d5d628/trunk/ga0/etc/logrotate.d/k.txt
xxx.xxx.xxx.xxx - svnuser [18/Mar/2009:22:02:59 -0400] "PUT /ivr/!svn/wrk/b2fd0c12-ff99-b94c-8718-107905d5d628/trunk/ga0/etc/logrotate.d/k.txt HTTP/1.1" 200 -
xxx.xxx.xxx.xxx - - [18/Mar/2009:22:02:59 -0400] "PUT /ivr/!svn/wrk/b2fd0c12-ff99-b94c-8718-107905d5d628/trunk/ga0/etc/logrotate.d/k.txt HTTP/1.1" 502 1406
xxx.xxx.xxx.xxx - svnuser [18/Mar/2009:22:02:59 -0400] "DELETE /ivr/!svn/act/b2fd0c12-ff99-b94c-8718-107905d5d628 HTTP/1.1" 204 -
/////////////////////////
Everything commits so far. Even having the file names as /bin/kill, but if there is any clearline text that has /bin/kill the commit will fail.
This has been reproduced on various other systems, but would like to know if anyone has seen or heard of this before, and can confirm my results, or denounce my results. As an additional note. svn commiting dirrectly to the master server even using the dav_svn does not exhibit these problems. Which leads me to believe it might be something with mod_proxy in apache.
Any help would be great.
~jonathan
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.