Not sure where to start, so I’ll just jump in…
I have a dRuby server which runs a thread for each request.
The request fires off some processing that includes working with
FireRuby and libxml, libxsl.
Here’s the weird thing about this. When I start the dRuby server, it
always throws a FireRuby exception when the libxml opens an xml file for
xsl transformation. But, it only does this the first time the server is
called. All subsequent calls to the dRuby server run all code as
designed without any trouble.
Now, I think it very odd that libxml appears to be throwing a fireruby
exception. But even more so is that this only happens the first time.
I feel that something isn’t getting initialized properly; but obviously
I don’t know what.
Any ideas on what might be happening?
I realize code helps, however it quite a bit of code. Thus I’m not sure
what portion would be relevant.
any help is appreciated.
regards,
andy koch
On 5/3/07, Andy K. [email protected] wrote:
Not sure where to start, so I’ll just jump in…
Here’s the weird thing about this. When I start the dRuby server, it
always throws a FireRuby exception when the libxml opens an xml file for
xsl transformation. But, it only does this the first time the server is
called. All subsequent calls to the dRuby server run all code as
designed without any trouble.
Have you tried running the code locally, i.e. not remotely via druby?
Distributed Ruby tends to mask exceptions thrown by the called process
in many cases in my experience, and the error you get tends to get
obscured by the time it gets to the remote caller. All you know is
that there was an error of some kind, just not what error it was. I
have a couple of very large projects that use druby extensively, and
this sort of behavior was so frustrating that I’ve made it a point to
test any code intended to be run via drb by executing it locally
first, and making sure that error handling is as bulletproof and
robust as I can make it. It seems highly unlikely to me that libxml is
really throwing your fireruby exception, more likely it’s throwing
some other exception that winds up getting masked as one by the time
it gets to the druby client.