You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2003/03/27 01:21:39 UTC
stress.pl failing over ra_svn
Hello
The tools/dev/stress.pl script is failing when I run it over
ra_svn. The script currently recognises three commit errors as being
"valid" i.e. errors that can occur naturally during normal operation.
These are:
"Transaction is out of date"
"Merge conflict during commit"
"Baseline incorrect"
Now when I run the script over ra_svn commits that fail usually give
"Network connection closed unexpectedly"
which looks suspicious to me. I have used the patch at the end of
this mail to make the script recognise the new error, and then I see
that occasionally commits do fail with one of the three "valid"
errors, the "Transaction is out of date" error say, but the new error
is the most common. I tried backing out the most recent ra_svn changes
and it made no difference.
So to my questions
- Is ra_svn supposed to report all commit errors?
- Does the "Network connection closed unexpectedly" error indicate a
protocol problem?
I have so far failed to determine exactly what is happening when the
"Network connection closed unexpectedly" error occurs. I'd rather not
add such a general error to the script's list of "valid" commit errors
if possible.
Here is how I run the script over ra_svn. In the first xterm run
$ svnserve -d -r .
$ path/to/stress.pl -c -s0 -U svn://localhost/repostress
and in the second xterm run
$ path/to/stress.pl -s0 -U svn://localhost/repostress
One of these will fail with an error something like
Transmitting file data ....subversion/libsvn_client/commit.c:618: (apr_err=210002)
svn: Network connection closed unexpectedly
svn: Commit failed (details follow):
subversion/libsvn_ra_svn/marshal.c:167: (apr_err=210002)
svn: Connection closed unexpectedly
Index: tools/dev/stress.pl
===================================================================
--- tools/dev/stress.pl (revision 5480)
+++ tools/dev/stress.pl (working copy)
@@ -167,6 +167,8 @@
Merge[ ]conflict[ ]during[ ]commit
|
Baseline[ ]incorrect
+ |
+ Network[ ]connection[ ]closed[ ]unexpectedly
)
$/x );
}
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl failing over ra_svn [PATCH]
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 28, 2003 at 11:03:53AM -0500, Greg Hudson wrote:
> On Thu, 2003-03-27 at 10:31, Philip Martin wrote:
> > I am using the following patch which lets me run stress.pl over
> > ra_svn. However I am not altogether happy about the way it drops all
> > the errors in svnserve/serve.c:commit. Perhaps "acceptable" and
> > "unacceptable" errors need to be distinguished, with only the former
> > being dropped?
>
> Hm. I'm afraid I didn't do a great job of sorting out what state the
> protocol should be in after an error. Perhaps it would be simplest if
> all errors are followed by a close of connection; I'm not sure if there
> is a case where this would be a bad thing. (This has implications for
> the ra_lib interface, of course; it means if you get an error from any
> ra_lib function or subsidiary editor or reporter function, you must
> create a new ra_lib session in order to do anything else.)
Hunh? That doesn't hold. You can lazily re-open the connection upon the next
RA operation that requires talking to the server.
(Neon auto-reconnects on the next request whenever the connection drops)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl failing over ra_svn [PATCH]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-03-27 at 10:31, Philip Martin wrote:
> I am using the following patch which lets me run stress.pl over
> ra_svn. However I am not altogether happy about the way it drops all
> the errors in svnserve/serve.c:commit. Perhaps "acceptable" and
> "unacceptable" errors need to be distinguished, with only the former
> being dropped?
Hm. I'm afraid I didn't do a great job of sorting out what state the
protocol should be in after an error. Perhaps it would be simplest if
all errors are followed by a close of connection; I'm not sure if there
is a case where this would be a bad thing. (This has implications for
the ra_lib interface, of course; it means if you get an error from any
ra_lib function or subsidiary editor or reporter function, you must
create a new ra_lib session in order to do anything else.)
I think your patch should be fine for the moment.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl failing over ra_svn [PATCH]
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> The problem occurs when a second commit starts while the first commit
> is in progress, and both commits modify the same file. This causes
> svn_repos_fs_commit_txn to return SVN_ERR_FS_CONFLICT, which
> propagates to svn_ra_svn_handle_commands where it gets written using
> svn_ra_svn_write_cmd_failure. So far so good.
>
> Now the commit function in svnserve/serve.c calls the function
> svn_ra_svn_drive_editor with pass_through set FALSE so the
> SVN_ERR_FS_CONFLICT error does not get returned. The commit function
> therefore goes on to call svn_ra_svn_write_tuple with unitialized
> new_rev, date, and author which causes svnserve to dump core.
>
> This core dump happens before svn_ra_svn_flush gets a chance to flush
> the SVN_ERR_FS_CONFLICT error to the client. This is what causes the
> client to report the network connection as closed.
I am using the following patch which lets me run stress.pl over
ra_svn. However I am not altogether happy about the way it drops all
the errors in svnserve/serve.c:commit. Perhaps "acceptable" and
"unacceptable" errors need to be distinguished, with only the former
being dropped?
Fix a bug where an SVN_ERR_FS_CONFLICT error raised during commit did
not get back to the client.
* subversion/libsvn_ra_svn/marshal.c (svn_ra_svn_handle_commands): Flush
after writing a failure response. Don't ignore errors.
* subversion/svnserve/serve.c (commit): Only write the rev/date/author
if the commit completed without error.
Index: ../svn/subversion/libsvn_ra_svn/marshal.c
===================================================================
--- ../svn/subversion/libsvn_ra_svn/marshal.c (revision 5483)
+++ ../svn/subversion/libsvn_ra_svn/marshal.c (working copy)
@@ -643,9 +643,17 @@
"Unknown command '%s'", cmdname);
if (err)
{
- svn_ra_svn_write_cmd_failure(conn, subpool, err);
+ svn_error_t *err2 = svn_ra_svn_write_cmd_failure(conn, subpool, err);
+ if (! err2)
+ err2 = svn_ra_svn_flush (conn, subpool);
if (pass_through_errors)
- return err;
+ {
+ svn_error_clear (err2);
+ return err;
+ }
+ svn_error_clear (err);
+ if (err2)
+ return err2;
}
svn_error_clear(err);
apr_pool_clear(subpool);
Index: ../svn/subversion/svnserve/serve.c
===================================================================
--- ../svn/subversion/svnserve/serve.c (revision 5483)
+++ ../svn/subversion/svnserve/serve.c (working copy)
@@ -352,6 +352,7 @@
svn_boolean_t aborted;
commit_callback_baton_t ccb;
svn_revnum_t new_rev;
+ svn_error_t *err;
SVN_ERR(svn_ra_svn_parse_tuple(params, pool, "c", &log_msg));
SVN_CMD_ERR(must_not_be_read_only(b));
@@ -362,10 +363,12 @@
b->repos_url, b->fs_path, b->user,
log_msg, commit_done, &ccb, pool));
SVN_ERR(svn_ra_svn_write_cmd_response(conn, pool, ""));
- SVN_ERR(svn_ra_svn_drive_editor(conn, pool, editor, edit_baton, FALSE,
- &aborted));
- SVN_ERR(svn_ra_svn_write_tuple(conn, pool, "r(?c)(?c)",
- new_rev, date, author));
+ err = svn_ra_svn_drive_editor(conn, pool, editor, edit_baton, TRUE, &aborted);
+ if (err)
+ svn_error_clear (err); /* ### Should some errrors be returned? */
+ else
+ SVN_ERR(svn_ra_svn_write_tuple(conn, pool, "r(?c)(?c)",
+ new_rev, date, author));
return SVN_NO_ERROR;
}
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl failing over ra_svn
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Wed, 2003-03-26 at 20:21, Philip Martin wrote:
> > "Network connection closed unexpectedly"
>
> There are known places in ra_svn where an error will cause the svnserve
> process to terminate rather than presenting an error to the client. The
> most tricky of these to fix is in the interface between the reporter and
> editor, since you don't know what state the protocol is in when you get
> an error back from a finish-report function.
>
> However, commits do not involve the reporter, nor are they one of the
> few other places where errors aren't reported right. From looking at
> the code, I don't see what kind of error would not be properly reported
> to the client. So I think some debugging is in order. (Unfortunately,
> I am very thin on time right now; things should ease up in a few
> months.)
The problem occurs when a second commit starts while the first commit
is in progress, and both commits modify the same file. This causes
svn_repos_fs_commit_txn to return SVN_ERR_FS_CONFLICT, which
propagates to svn_ra_svn_handle_commands where it gets written using
svn_ra_svn_write_cmd_failure. So far so good.
Now the commit function in svnserve/serve.c calls the function
svn_ra_svn_drive_editor with pass_through set FALSE so the
SVN_ERR_FS_CONFLICT error does not get returned. The commit function
therefore goes on to call svn_ra_svn_write_tuple with unitialized
new_rev, date, and author which causes svnserve to dump core.
This core dump happens before svn_ra_svn_flush gets a chance to flush
the SVN_ERR_FS_CONFLICT error to the client. This is what causes the
client to report the network connection as closed.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl failing over ra_svn
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-03-26 at 20:21, Philip Martin wrote:
> "Network connection closed unexpectedly"
There are known places in ra_svn where an error will cause the svnserve
process to terminate rather than presenting an error to the client. The
most tricky of these to fix is in the interface between the reporter and
editor, since you don't know what state the protocol is in when you get
an error back from a finish-report function.
However, commits do not involve the reporter, nor are they one of the
few other places where errors aren't reported right. From looking at
the code, I don't see what kind of error would not be properly reported
to the client. So I think some debugging is in order. (Unfortunately,
I am very thin on time right now; things should ease up in a few
months.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org