You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Glenn A. Thompson" <gt...@cdr.net> on 2003/06/06 20:45:38 UTC
[PATCH] experimental FS set_errcall logging
Hey,
When Karl mentioned wanting a patch for set_errfile logging stuff I
decided to try my hand at it.
Here some things that drove my approach.
1. I believe that using set_errcall is more flexible than using
set_errfile.
2. Being flexible, it will better allow us to hook into something like
http://log4c.sourceforge.net/. I said *like* :-)
3. Also allows the detail to be returned in the error chain. Which is
helpful when server and user are not co-located.
4. In case of an error, BDB would have to call the CB function before
returning control to the caller. It would be useless otherwise.
I could save it and use it later.
5. It seemed possible that BDB may also call the callback more than
once for certain errors or call it when not reporting an error.
6. To cover the case where no error is returned I need to cleanup the
leaky messages.
7. BDB does not provide "REAL" opaque user_data. They expect the error
prefix to be a C string.
If you read: http://www.sleepycat.com/docs/api_c/db_err.htm and
http://www.sleepycat.com/docs/api_c/env_set_errpfx.html
You will notice that it maintains a reference to the prefix and
does not add it to the message when a set_errcall has registered
a callback. So we have a cheesy userdata field. (More on this to
follow).
The approach:
1. Register a callback which creates svn_error_t's and chains them off
each other saving them in the svn_fs_t object.
2. When an error occurs, detach the error chain and use it as the child
parameter to the svn_error_create call.
3. Mutex protect these operations so multiple threads can use the the
same fs object.
4. Clear out the error chain when svn_fs_t object goes out of scope.
Some caveats:
1. It's not completely tested. "experimental"
2. The changes that are in tree.c were just a cheesy way to test. I
patch tree.c then run a couple stress.pls.
Tree.c is not part of the patch. I simulate BDB error logging
using err and errx.
3. I have two ways I pass the fs object through the callback:
One which uses the pointer(way to dangerous) in the prefix
parameter and the other which places the addr as a string in the prefix
parameter. Currently it uses apr_snprintf and scanf for this, but
I could roll my own for both sides if folks think it will be safer.
4. If folks want the patch I'll write a *real* test for this patch. If
not, it was worth the shot. We can file it under /dev/null.
The patch and log entry are at
http://www.cdrguys.com/subversion/logpatch1.tar
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] experimental FS set_errcall logging
Posted by Sander Roobol <ph...@wanadoo.nl>.
Filed as issue #1358.
Sander
On Fri, Jun 06, 2003 at 04:45:38PM -0400, Glenn A. Thompson wrote:
> Hey,
>
> When Karl mentioned wanting a patch for set_errfile logging stuff I
> decided to try my hand at it.
>
> Here some things that drove my approach.
>
> 1. I believe that using set_errcall is more flexible than using
> set_errfile.
> 2. Being flexible, it will better allow us to hook into something like
> http://log4c.sourceforge.net/. I said *like* :-)
> 3. Also allows the detail to be returned in the error chain. Which is
> helpful when server and user are not co-located.
> 4. In case of an error, BDB would have to call the CB function before
> returning control to the caller. It would be useless otherwise.
> I could save it and use it later.
> 5. It seemed possible that BDB may also call the callback more than
> once for certain errors or call it when not reporting an error.
> 6. To cover the case where no error is returned I need to cleanup the
> leaky messages.
> 7. BDB does not provide "REAL" opaque user_data. They expect the error
> prefix to be a C string.
> If you read: http://www.sleepycat.com/docs/api_c/db_err.htm and
> http://www.sleepycat.com/docs/api_c/env_set_errpfx.html
> You will notice that it maintains a reference to the prefix and
> does not add it to the message when a set_errcall has registered
> a callback. So we have a cheesy userdata field. (More on this to
> follow).
>
> The approach:
>
> 1. Register a callback which creates svn_error_t's and chains them off
> each other saving them in the svn_fs_t object.
> 2. When an error occurs, detach the error chain and use it as the child
> parameter to the svn_error_create call.
> 3. Mutex protect these operations so multiple threads can use the the
> same fs object.
> 4. Clear out the error chain when svn_fs_t object goes out of scope.
>
> Some caveats:
> 1. It's not completely tested. "experimental"
> 2. The changes that are in tree.c were just a cheesy way to test. I
> patch tree.c then run a couple stress.pls.
> Tree.c is not part of the patch. I simulate BDB error logging
> using err and errx.
> 3. I have two ways I pass the fs object through the callback:
> One which uses the pointer(way to dangerous) in the prefix
> parameter and the other which places the addr as a string in the prefix
> parameter. Currently it uses apr_snprintf and scanf for this, but
> I could roll my own for both sides if folks think it will be safer.
> 4. If folks want the patch I'll write a *real* test for this patch. If
> not, it was worth the shot. We can file it under /dev/null.
>
> The patch and log entry are at
> http://www.cdrguys.com/subversion/logpatch1.tar
>
> gat
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org