"Adam Nichols" <adam_at_dc949.org> wrote on 09/17/2008 09:49:13 PM:
> The error message is from apache, but if the client is sending the
> wrong size in the header, it would cause the error by no fault of
> apache.
Excellent point. I was blaming the server, but it could be the client.
(Or even both could be wrong.)
Now I'm using stock apache 2.2.9 (from apache.org) on Windows server 2003
and the stock win32 svn 1.5.1 apache modules for apache 2.2 on one
server, and a self compiled apache 2.2.8 and svn 1.5.1 on the
solaris server.
I've tried the pre-compiled win32 1.5.1 distribution and TortoiseSVN 1.5.3
on Windows, and my self compiled command svn 1.5.1 executables on
solaris.
All the variations from client to server using the http protocol
fail with a 413 error on a 4G file. (svn protocol works fine)
I'm using apache 2.2.8 from source on solaris, since the apr 1.3
LDAP stuff seems to be quite broken in apache 2.2.9.
Looks like I'm using neon 0.28.2, so I'll update that when
I rebuild svn 1.5.2 on solaris and see if anything changes...
Thanks for the config info.
Kevin R.
> Berkley DB 4.4.20
> I didn't write down the options I used here, but I believe the only
> option I gave this was --prefix=/usr
>
> apr-1.3.3:
> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/etc
--with-gnu-ld
>
> apr-util-1.3.4
> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/etc
> --with-gnu-ld --with-apr=/usr --with-berkeley-db=/usr
>
> neon-0.28.3
> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
> --with-gnu-ld --with-ssl --with-zlib --enable-shared
>
> subversion-1.5.1
> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
> --with-gnu-ld --without-berkeley-db --without-zlib --without-jdk
> --without-jikes --without-swig --without-junit
>
> httpd-2.2.9
> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
> --enable-ssl --enable-dav --enable-http --enable-so --enable-rewrite
>
> To preempt the question... I'm not sure why I omitted BerkleyDB
> support in subversion but included it in apr-util. At any rate, these
> options worked for me on Linux 2.6.15.5; good luck with Solaris.
>
> --Adam
>
> On Thu, Sep 18, 2008 at 12:45 AM, <kmradke_at_rockwellcollins.com> wrote:
> >
> > "Adam Nichols" <adam_at_dc949.org> wrote on 09/17/2008 04:54:05 PM:
> >> A little info on the disk thrashing & lack of network activity:
> >>
> >> It's apparently doing a diff which is what all that hard drive and
CPU
> >> activity is about before the network traffic kicks in. I found this
> >> out when I got an error about not having enough disk space. I've
read
> >> that it uses /tmp but when I made /tmp a symlink to a large drive, it
> >> still failed with the same message, so I'm not sure where the
> >> temporary file is stored. Once it gets the difference, I believe it
> >> sends it off for a library like neon to handle.
> >>
> >> I can't say for sure if it's a problem with neon or with creating the
> >> temporary file, but I know that re-compiling with everything and
using
> >> the latest versions of all software solved the problem. My
> >> configuration options were just to specify where to find neon, apr,
> >> apr-util, berkleydb, etc. If anyone is interested in the exact
config
> >> options, I can see if I can dig them up for you when I get back to
the
> >> computer I used to compile it.
> >
> > I would be interested in the configure options, since I compile from
> > source on our Solaris server. The windows one is stock apache 2.2.9
> > and from the svn .zip file. I was planning on upgrading to svn 1.5.2,
> > to see if that made and difference from 1.5.1, but haven't had the
time yet.
> >
> > Since the 413 error is from apache, I would assume the apache/apr
> > options are the most important...
> >
> > Kevin R.
> >
> >>
> >> --Adam
> >>
> >> On Wed, Aug 27, 2008 at 2:38 PM, <kmradke_at_rockwellcollins.com>
wrote:
> >> >
> >> > "Adam Nichols" <adam_at_dc949.org> wrote on 08/27/2008 10:24:46 AM:
> >> >> I upgraded to apache httpd 2.2.9, apr-1.3.3 and apr-util-1.3.4
> >> >>
> >> >> Additional info from the errorlog:
> >> >> [Tue Aug 26 20:28:51 2008] [error] [client 192.168.192.187]
Invalid
> >> >> Content-Length
> >> >> [Tue Aug 26 20:28:51 2008] [error] [client 192.168.192.187] Could
not
> >> >> get next bucket brigade [500, #0]
> >> >>
> >> >> I tried changing the LimitXMLRequestBody to 10240 to make sure it
was
> >> >> taking effect, and that resulted in a much quicker failure (about
17
> >> >> seconds instead of 8minutes). So I know the directive is being
set to
> >> >> 0 properly.
> >> >>
> >> >> I tried it from the server itself and connected to
https://localhost
> >> >> and it went through with no problem. So it looks like this might
> >> >> actually be a problem with the client side and not the server
side. I
> >> >> was using subversion 1.5.1 on both machines, but they were
compiled
> >> >> with different options. I'll look into it tonight when I get back
> >> >> from work.
> >> >
> >> > I can reproduce this with apache 2.2.8/svn 1.5.1 on both windows
and
> >> > solaris as servers using both TortoiseSVN 1.5.2 and the svn 1.5.1
> >> > command line on windows using a single 4G file.
> >> >
> >> > 2G files worked fine in the past with svn 1.4.6. Not sure I ever
> >> > tried one quite this large before.
> >> >
> >> > The thing I noticed is the client is thrashing the disk for about 8
> >> > minutes and it never seems to send much network traffic during
> >> > the time before it fails...
> >> >
> >> > Kevin R.
> >> >
> >> >> --Adam
> >> >>
> >> >> On Mon, Aug 25, 2008 at 12:04 AM, Adam Nichols <adam_at_dc949.org>
wrote:
> >> >> > I'm using subversion 1.5.1 and am unable to upload large files
(the
> >> >> > one I'm trying to upload is over 4GB). It looks like subversion
> >> >> > should be able to handle this, however I get "svn: PUT of
> >> >> >
> >> >> >
> >> >> >
'/!svn/wrk/2c6a8c20-0b88-457d-836a-118fa1ca5a3b/FILE_I_AM_TRYING_TO_UPLOAD':
> >> >> > 413 Request Entity Too Large (https://HOSTNAME)" when I try to
import
> >> >> > the file.
> >> >> >
> >> >> > I was looking through the archives and it looks like the only
> >> >> > solution
> >> >> > proposed was about client side certs (which I do not use).
Source:
> >> >> >
> >> >> >
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=73988
> >> >> >
> >> >> > According to the manual, the solution is to use the
> >> >> > LimitXMLRequestBody directive.
> >> >> > http://publib.boulder.ibm.com/httpserv/manual60/mod/mod_dav.html
> >> >> >
> >> >> > Does subversion support files over 2GB? If so, can someone
point me
> >> >> > in the right direction on what I'm doing wrong in my config?
> >> >> >
> >> >> > Below are the relevant config options from my apache
configuration:
> >> >> >
> >> >> > LimitRequestBody 0
> >> >> > LimitXMLRequestBody 0
> >> >> >
> >> >> > DavLockDB "/var/lock/DavLock"
> >> >> >
> >> >> > <Location />
> >> >> > DAV svn
> >> >> > SVNPath /mnt/monster/svn
> >> >> >
> >> >> > AuthType Basic
> >> >> > AuthName "Subversion Repository"
> >> >> > AuthUserFile /etc/svn_htpasswd
> >> >> > Require valid-user
> >> >> > SSLRequireSSL
> >> >> > </Location>
> >> >> >
> >> >> >
> >> >> >
> >> >> > Thanks,
> >> >> > Adam
> >> >> >
> >> >>
> >> >>
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> >> >> For additional commands, e-mail: users-help_at_subversion.tigris.org
> >> >>
> >> >
> >
Received on 2008-09-18 16:48:58 CEST