This may be entirely the wrong forum for this message, but I wanted to give
it a try.
I am creating an ASPX page, with C# code behind, and am calling on a C#
helper class, which in turn is wrapping a lot of functionality from a
vendor's SDK. The SDK (which I have no source for, or visibility into) is
actually Java-based; they wrote a COM (or COM+) wrapper for it long ago, and
more recently created a .NET wrapper for *that*.
I have a number of problems that I'm trying to work through. The most
pressing is one that my program runs perfectly the first time through, but
then the second time I try it (with identical arguments), an exception is
raised to the UI thread (object reference not set to an instance object) and
my UI exits. Meanwhile, in the IIS 6.0 worker process, my method call
continues to work, sending output to my log file till it completes normally.
Of course, when it attempts to return that result to the UI thread, the UI
thread has long since ended. Sort of like a kid who comes back from camp to
find that his parents have moved.
Based on this behavior, I'm postulating that the SDK has made some sort of
asynchronous call to a sister program, and if there's any issue, major or
minor, the async call throws an exception, which goes for the UI thread,
rather than being caught in my local try/catch.
Any later calls to my program (which go to the SDK and in turn, to the JVM
hanging around in the IIS worker process) seem pretty much hosed as well,
throwing either the same "object reference not set to an instance object"
error, or (more interestingly) a
"org.apache.xerces.jaxp.DocumentBuilderFactory Impl not found" error, even
though this class is most definitely on the classpath. The error information
coming back seems very limited (Message and StackTrace from the exceptions
have little useful content...I'm wondering if all the useful stuff was
stripped out in one of the numerous wrappers).
Restarting IIS gets rid of the errors, and allows me one error-free run of
the program. However, restarting IIS after each request doesn't seem like a
viable strategy.
My questions would be:
(1) Is there any way to divert any potential async errors from the UI thread
to (for example) the NET equivalent of /dev/null? Or better still, disable
any async calls?
(2) More broadly, are there any best practices for isolating an
ill-mannered, untrustworthy SDK?
(3) How would you deal with a problem such as the one described above?
Tracking down the original developer of the SDK and smacking him on the head
with a cast-iron skillet might be satisfying, but seems to do little to
solve my problem.
I'm not going to name the vendor, even though it's a totally crappy product,
and, has proven to be supported in name only (the engineers/developers
appear to be refusing to answer any queries from front-line support, even
after several weeks).
Thanks very much for any assistance or suggestions you might offer!
JDK
