Archives

Archives / 2003 / November
  • Lessons Learned

    When using a COM component created by a company known for their great cross platform statistics software, but not known for their Windows expertise, creates a COM component and sets the component’s threading model to both (STA and MTA models), don’t trust it.  If said component was developed for and tested against VB 6.0 and you are using .Net, don’t trust that it can handle MTA, even though their sample .Net code never checks to make sure it is running on STA thread.  And if you are really foolish enough to try to use this component in a multithreaded service, and it works “almost” all the time, but occasionally hangs all threads in the process, the first thing you should do is make sure all threads that call the component have their ApartmentState set to STA.  Then make sure that the wrapper dll that you wrote to make life easier to deal with this crazy component checks the thread’s ApartmentState, and throws an error if it isn’t STA.

  • 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.

  • New Blogging Home

    I finally got .Text up and running as my CMS on my home page and that's where the majority of my posts will be from now on.  I'm not totally leaving weblogs.asp.net , but I will only post  pure .Net stuff here.  Stuff  like SVG, XML, Longhorn, PDC, and various non-tech topics will only be found on my home page.  The idea is to try to help reduce the noise from weblogs.asp.net, and have the freedom to post “offtopic” stuff as I wish.  Only the front page is skinned to me new style (and that isn't even totally complete yet).  The individual category pages still use the default .Text styles.