When Good Programs Go Bad

Ahhhhh!  I hate it when good programs go bad.  As you can probably tell from the lack of good quality posts lately, I’ve been busy with work.  At my client, we are at the end of our development cycle, and getting ready for formal testing (thanks to all the FDA requirements it takes about 3 times as long as it should).  Everything was looking good except for the most complicated piece of code (which of course is mine).  Basically, I wrote a .Net data provider for SAS, and placed that in my Data Access Layer.  I re-engineered the Async Application block to work with my Line of Business code (and removed all the SQL Server stuff), which calls my Data Access Layer which calls either the Oracle Provider or my SAS provider.  The .Net SAS provider calls a COM dll (provided by SAS) via COM interop, and the COM component talks to a Unix box via a TCP/IP.  Lots of places for things to go wrong, and unfortunately, something does go wrong occasionally (but not always).  I can’t see to track down exactly what goes wrong, but the net result is sometimes a worker thread makes a call to the SAS server, (via the SAS provider and the COM component) and it never stops waiting for a response.  I can check the SAS process on the Unix box, and it says it has completed and is closing the connection, but either the COM component never gets the close message, or the COM interop never fires the complete event (or even the error event).  We have all sorts of network issues, so it could be a network issue, so I’ve got to do some network sniffing.  Or, it could be COM interop causing the problems.  I thought it could be a multi-threading issue, but I still get the problem occasionally when single threaded.

I’ve got until next Wed. to figure this one out, so it looks like I’ll be busy for a while.

DonXML

 The preceding blog entry has been syndicated from the DonXML Demsak’s All Things Techie Blog.  Please post all comments on the original post, and not this one.