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.
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
>> >>
>> >
>
---------------------------------------------------------------------
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-19 07:46:15 CEST