One of the reasons why you shouldn't use Word automation on web server



  • Although Microsoft specifically discourages such practice, some people think that wasting 300 Meg of RAM on production server with 2 GB RAM and SQL server eating typically half of it isn't such a bad thing.

    Winword likes to stay alive

     But it's easier to program that way, eh? And you got nice word documents right out of your web application!

     T
     



  • <Shiver/>



  • I have some trouble understanding how exactly you get so many instances of Word.

    Does some web application automatically open Word and never closes it again? Is there a way to prevent this and still be able to create Word documents in your web application?
     



  • I've actually seen this before.  The problem is, if I recall correctly, the Word API has an extra step required for closing.  There are two methods: Close() and Quit().  You have to call Close() for every document you have open, and then Quit() on the Word object itself.  If you just call Close() like you would with a db connection, you end up with a bunch of processes still running.
     



  • I also remember that from my early desktop days. If you weren't extra careful, you would frequently end up with hanging Winword processes.

    It wouldn't be such a wtf if Microsoft's didn't make specific recommendations NOT to use Office server-side.

    See:  http://support.microsoft.com/kb/257757



  • [quote user="rmr"]

    I've actually seen this before.  The problem is, if I recall correctly, the Word API has an extra step required for closing.  There are two methods: Close() and Quit().  You have to call Close() for every document you have open, and then Quit() on the Word object itself.  If you just call Close() like you would with a db connection, you end up with a bunch of processes still running.
     

    [/quote]

    but that makes sense, right? IIRC, you use the "Application" interfaces/classes in conjunction with the "Document" ones. So quiting the app in that context is exactly what a user would do when finished with Word itself. Bad coder, bad!



  • [quote user="rmr"]

    I've actually seen this before.  The problem is, if I recall correctly, the Word API has an extra step required for closing.  There are two methods: Close() and Quit().  You have to call Close() for every document you have open, and then Quit() on the Word object itself.  If you just call Close() like you would with a db connection, you end up with a bunch of processes still running.

    [/quote]

    This can also be the case if you're invoking the API from .Net. To dispose off the COM objects without waiting for the garbage collection to happen (this can take 20 minutes to half an hour to rarely used webapps), one must call Marshal.ReleaseCOMObject() or something like that. But .Net developers, brought up in the automatic GC world, don't understand such stuff unless they've understood COM and how it implements reference counting.



  • I have something cheesier - try writing a simple html file. Heck, even throw in a table or two! Then rename the file from .html to .doc.

    When you double-click that doc, you will either feel like smacking yourself or kissing me. Don't hold back! 



  • [quote user="xsmasher"]

    I have something cheesier - try writing a simple html file. Heck, even throw in a table or two! Then rename the file from .html to .doc.

    When you double-click that doc, you will either feel like smacking yourself or kissing me. Don't hold back! 

    [/quote]

    Amen.  Why produce output in a proprietary format, when word will read so many standardized formats?  RTF and HTML come to mind.



  • I must admit to having a service called ExcelProcessKiller running on a server somewhere, checking for instances of Excel that have been around for more than a minute.

    At that time (pre 2003 XML) the users requirement for multiple tabs and other non-HTMLable stuff ether meant buying a proprietary add-in or taking your chances.

    I can confirm that whatever clean up work you do, sometimes the processes do just hang. Hence the clean-up service :(



  • from csv import writer

    mywriter = writer(mystream)
    mywriter.writerows(data)

    Okay, I know I'm over-simplifying, but often, that'd be a good enough solution, really.



  • Microsoft does advice against using automated Word in server environments and proposes for developers to work at XML level.

    This however is no excuse to cease development of such a service when you're halfway through .. apperantly.



  • MS Office adds a few extra wrinkles.  The COM libraries for Office automation specifically support the concept of launching Word from an app, generating a document, and then detaching and leaving Word running.  Because of this, even if you thouroghly destroy all of the COM objects, Word may still hang.  Excel is actually a worse offender than Word, but it can sometimes be tricky to get any of them to close.  Usually the culprit is that you used a collection without creating an explicit reference to it.  Then, you never remember to destroy it because you used it implicitly and you don't have a variable for it.  If you Call .Quit(), the GUI will go away, but the automation server will still hang out in memory.


Log in to reply