You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Russell Glaue <rg...@cait.org> on 2003/07/09 20:35:11 UTC
Issuezilla #1350 -- update
I logged in to tigris.org, however I cannot update issue #1350
http://subversion.tigris.org/issues/show_bug.cgi?id=1350
Can anyone tell me how to add a comment to this issue (or any issue) in
Issuezilla??
For those of you who have not read/experienced this issue, the brief
summary is that we are receiving RA layer errors due to server/client
timeout. It was recommended that we upgrade our Subversion Server to
0.24.2, that this issue seemed to disappear after version 0.23.0. We
have performed the upgrade, however we are still experiencing the same
problems.
I think it might not be reproducible by the developers because their
testing repository is not the same size as ours. Our content in this
one repository is over 300MB. We receive time-out errors on our
repositories over 180MB (our smallest is 180MB).
Some one Please tell me how I can update this ticket (Issuezilla
#1350)!! i want to submit the below information as a comment/update to
this issue/ticket.
Here is our comment/update to this issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=1350
In regards to the above URLed issue:
We have upgraded to Subversion 0.24.2, and are still experiencecing the
same timeout problems.
It might be worthy to note to the subversion developers the size of
the berkley database for that repository.
Perhaps this time-out issue occurs when the repository is a very large
size. (The real repository name is similar to http-org.web-domain)
unix~# pwd
/data/subversion/http-org.web-domain
unix~# du -ks .
1120192 .
unix~# du -ks db
1120120 db
unix~# du -ks db/* | grep -v "log.*"
4 db/DB_CONFIG
8 db/__db.001
268 db/__db.002
324 db/__db.003
724 db/__db.004
16 db/__db.005
2956 db/changes
8 db/copies
1128 db/nodes
2432 db/representations
8 db/revisions
361524 db/strings
56 db/transactions
8 db/uuids
The SVN client user reports the following happens:
He commits to the Subversion Server Repository 185 files in this one
instance, and he received an "svn: RA layer request failed" error while
"Transmitting file data......(etc)..."
Here is the summaried output of his terminal screen:
[MaxOSX~] % svn commit -m "level 1 changes" --username johnuser
Error validating server certificate: Unknown certificate issuer. Accept?
(y/N): y
Sending lev1/acknowledge.jsp
.
...yada...blah, blah, blah...
...yada...blah, blah, blah...more files....
.
Sending lev1/overview.jsp
Adding lev1/setup.jsp
Sending lev1/started.jsp
Transmitting file data
........................................................................
........................................................................
..........................svn:
RA layer request failed
svn: Commit failed (details follow):
svn: MERGE request failed on
'/svn/http-org.web-domain/trunk/webapps/de/vtlc/lev1'
svn: MERGE of '/svn/http-org.web-domain/trunk/webapps/de/vtlc/lev1':
timed out waiting for server (https://svn.cait.org)
When the user runs 'svn status' his local repository shows that nothing
had been committed to the repository. However when looking at the file
on the server, they appear to be the files he committed and which he
received the "RA Layer Error".
[MaxOSX~] % svn status
M acknowledge.jsp
M content/les1/activity1.jsp
M content/les1/activity2.jsp
M content/les1/p1.jsp
.
...yada...blah, blah, blah...
...yada...blah, blah, blah...more files....
.
A setup.jsp
M started.jsp
So the user runs 'svn update' and gets the message that the version
already exists and thus local svn client does not do an update to the
local repository.
The user then tries a svn cleanup. However there is no output and
nothing is done to the local repository to fix the problem.
It seems like all file changes are being committed to the server
correctly, but the client times-out waiting for the server to send it
feed back about the success/failure of the transaction/communication.
-RG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issuezilla #1350 -- update
Posted by Andy Wettstein <aw...@cait.org>.
On Wed, Jul 09, 2003 at 10:17:12PM +0100, Philip Martin wrote:
>
> > Transmitting file data
> > ........................................................................ ........................................................................ ..........................svn:
> > RA layer request failed
> > svn: Commit failed (details follow):
> > svn: MERGE request failed on
> > '/svn/http-org.web-domain/trunk/webapps/de/vtlc/lev1'
> > svn: MERGE of '/svn/http-org.web-domain/trunk/webapps/de/vtlc/lev1':
> > timed out waiting for server (https://svn.cait.org)
>
> If you send lots of items in a commit the server can take some time to
> respond. It is possible to increase the client timeout, look for
> http-timeout in ~/.subversion/servers.
We had changed the http-timeout to 120 on this machine several weeks
ago, when it was still runing 0.22.2, but we still had problems.
> > It seems like all file changes are being committed to the server
> > correctly, but the client times-out waiting for the server to send it
> > feed back about the success/failure of the transaction/communication.
>
> I think you are correct. Increase the client timeout, or buy a
> faster server!
The server is running on a P3 1Ghz machine with 512 MB RAM, how much
faster do we need to get?
>
> --
> Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issuezilla #1350 -- update
Posted by Philip Martin <ph...@codematters.co.uk>.
Russell Glaue <rg...@cait.org> writes:
> Can anyone tell me how to add a comment to this issue (or any issue)
> in Issuezilla??
You need to "join the project" on the subversion web page.
> Transmitting file data
> ........................................................................ ........................................................................ ..........................svn:
> RA layer request failed
> svn: Commit failed (details follow):
> svn: MERGE request failed on
> '/svn/http-org.web-domain/trunk/webapps/de/vtlc/lev1'
> svn: MERGE of '/svn/http-org.web-domain/trunk/webapps/de/vtlc/lev1':
> timed out waiting for server (https://svn.cait.org)
If you send lots of items in a commit the server can take some time to
respond. It is possible to increase the client timeout, look for
http-timeout in ~/.subversion/servers.
> When the user runs 'svn status' his local repository shows that nothing
> had been committed to the repository. However when looking at the file
> on the server, they appear to be the files he committed and which he
> received the "RA Layer Error".
>
> [MaxOSX~] % svn status
> M acknowledge.jsp
> M content/les1/activity1.jsp
> M content/les1/activity2.jsp
> M content/les1/p1.jsp
> .
> ...yada...blah, blah, blah...
> ...yada...blah, blah, blah...more files....
> .
> A setup.jsp
> M started.jsp
Yes, the client assumes that the commit failed, so all the local
modifications remain.
> So the user runs 'svn update' and gets the message that the version
> already exists and thus local svn client does not do an update to the
> local repository.
You haven't given the exact error message. I assume that it refers to
items that are in state 'A' rather than state 'M'.
> The user then tries a svn cleanup. However there is no output and
> nothing is done to the local repository to fix the problem.
You should not need a cleanup. If you only have items in state 'M'
then I would expect update to work. However any items in state 'A'
will need to be removed using 'svn rm --force' before the update will
work. Yes, that is a bit messy. I suppose we could attempt some sort
of recovery, one option would be for the client to compare the
contents of the locally added file with those of the file being added
by the update, if the contents are identical then the obstructed error
could be avoided. Another option would be for the client to install
the text-base but leave the working copy unchanged. Keyword expansion
and eol translation would need to be considered in either case.
> It seems like all file changes are being committed to the server
> correctly, but the client times-out waiting for the server to send it
> feed back about the success/failure of the transaction/communication.
I think you are correct. Increase the client timeout, or buy a
faster server!
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org