Re: Bug #12 done, for real
Peter McCurdy
>
> On 21/01/2008, Peter McCurdy <peterm...@alumni.uwaterloo.ca> wrote:
> > On Jan 21, 2008 11:44 AM, Avery Pennarun <apen...@gmail.com> wrote:
> > > Darn it. I once had a link to a great old paper out of Sun that
> > > explained the whole problem with RPC turned out to be in making things
> > > look too much like method calls, but I think I lost it.
> I think it's probably linked inside the proprietary NITI wiki somewhere...
I had a look and couldn't find it. Any idea at all on what page it
might have been on? It wasn't on your personal page, nor could I find
any pages dedicated to RPC (other than the RapidPrototypingContests,
of course).
> In general, I'd someday like to use a WvError-like thingy in
> versaplexd. But for now, I think your idea of a particular exception
> class will do the job. Basically:
>
> 1) If it's a VxRequestException, take the message (not stack trace)
> and send it back as an error in response to the given request. Also
> log it at a debug level.
>
> 2) If it's any other kind of exception, send back a meaningless "fatal
> error" type message to the sender - because all method call messages
> should always get an answer, but we don't want to reveal our bugs to
> the client - and then log all the actual details from versaplexd.
This is now done. I think part of my confusion was I was thinking of
config errors as being an internal server problem, when they can quite
easily be a client problem as well, so need to be sent on. Anyway, it
works fairly well. It'd be possible to elaborate on the error message
by taking the message from the inner exception if there is one, but I
decided to keep it short. The full stack logging is just to the
console, as I didn't see any other logging stuff around. For the
record, it was Versaplex that was forwarding on all exceptions, not
dbus-sharp.
As you've probably noticed, I also fixed up everything else I could
think of that needs doing, so I'm pretty confident in declaring myself
done. Feel free to inform me otherwise if I've forgotten something.
Peter.
Avery Pennarun
> I had a look and couldn't find it. Any idea at all on what page it
> might have been on? It wasn't on your personal page, nor could I find
> any pages dedicated to RPC (other than the RapidPrototypingContests,
> of course).
Probably under DistributedFileSystems or something of the sort.
> This is now done. I think part of my confusion was I was thinking of
> config errors as being an internal server problem, when they can quite
> easily be a client problem as well, so need to be sent on. Anyway, it
> works fairly well. It'd be possible to elaborate on the error message
> by taking the message from the inner exception if there is one, but I
> decided to keep it short.
This is good for security reasons; if we weren't expecting the
exception, we certainly don't know if it should be reported outside
the highly secure datacentre or not.
> The full stack logging is just to the
> console, as I didn't see any other logging stuff around. For the
> record, it was Versaplex that was forwarding on all exceptions, not
> dbus-sharp.
That's good news, in its own way.
> As you've probably noticed, I also fixed up everything else I could
> think of that needs doing, so I'm pretty confident in declaring myself
> done. Feel free to inform me otherwise if I've forgotten something.
It all looks good to me now. There were some portability problems
introduced (pwd.h and friends aren't available in win32) but I sorted
those out. Andrei is working on a python-gtk application that can do
database queries straight over dbus to versaplexd. It seems to be
working, although he had to implement a simple missing
org.freedesktop.DBus method in wvdbusd. So this all looks good now.
Have fun,
Avery
Peter McCurdy
>
> On 24/01/2008, Peter McCurdy <peterm...@alumni.uwaterloo.ca> wrote:
> > I had a look and couldn't find it. Any idea at all on what page it
> > might have been on? It wasn't on your personal page, nor could I find
> > any pages dedicated to RPC (other than the RapidPrototypingContests,
> > of course).
>
> Probably under DistributedFileSystems or something of the sort.
No dice. Oh well.
> > This is now done. I think part of my confusion was I was thinking of
> > config errors as being an internal server problem, when they can quite
> > easily be a client problem as well, so need to be sent on. Anyway, it
> > works fairly well. It'd be possible to elaborate on the error message
> > by taking the message from the inner exception if there is one, but I
> > decided to keep it short.
>
> This is good for security reasons; if we weren't expecting the
> exception, we certainly don't know if it should be reported outside
> the highly secure datacentre or not.
Well, the one thing in particular this hurts is that you now don't get
the actual syntax error in your SQL query pointed out if MS SQL
doesn't like it. If we want to fix that though, we can catch the
VxSqlException specifically and give the server's error message.
> > As you've probably noticed, I also fixed up everything else I could
> > think of that needs doing, so I'm pretty confident in declaring myself
> > done. Feel free to inform me otherwise if I've forgotten something.
>
> It all looks good to me now. There were some portability problems
> introduced (pwd.h and friends aren't available in win32) but I sorted
> those out. Andrei is working on a python-gtk application that can do
> database queries straight over dbus to versaplexd. It seems to be
> working, although he had to implement a simple missing
> org.freedesktop.DBus method in wvdbusd. So this all looks good now.
Hooray! I'll send along an invoice soon.
Peter.
Andrei Thorp
Nice working with you. Thank you for the fixes.
-Andrei Thorp
Avery Pennarun
> On Jan 24, 2008 4:52 PM, Avery Pennarun <apen...@gmail.com> wrote:
> > This is good for security reasons; if we weren't expecting the
> > exception, we certainly don't know if it should be reported outside
> > the highly secure datacentre or not.
>
> Well, the one thing in particular this hurts is that you now don't get
> the actual syntax error in your SQL query pointed out if MS SQL
> doesn't like it. If we want to fix that though, we can catch the
> VxSqlException specifically and give the server's error message.
That's the kind of exception we *should* be returning back to the
user, because it's caused by something that's their fault. On the
other hand, if, say, we run an auto-generated SQL request in response
to some other user request (not currently defined), we'd want to hide
the exact nature of the error from the client.
Have fun,
Avery