Re: [Wrapper-user] Wrapper causes zombie procecesses started from Runtime.getRuntime( exec ( cmd ) );

[Eoin C. <eo...@pe...>]

Ted,

Some other things you could check to try and narrow it down:

Does the problem occur with any script, or only if the script uses 
excel? Does it occur with any sheet or only this one?

You say you call the script asynchronously - in your tests are there 
more than one vbsript process executing simultaneously?

Now that you have StreamGobbler, you could stick in some 
Console.writeln's and see if the process get's stuck at a certain point 
in the script, or after the script exits?


eoin.


Ted Hudacko wrote:

>Leif and Sal,
>Leif, Sal,
>
>Thank you very much for detailed your responses.  You have given me a
>multiple areas to investigate, but I may have already been down some of
>these paths.
>
>1) Possible unacknowledged error dialogs:
>I was reasonably certain that the line in my VB script:
>  objExcel.DisplayAlerts = False
>
>would suppress error dialogs to the user.   And I did thoroughly test the VB
>script standalone (from the console) and from JBoss unwrapped.  But I will
>revisit this as a possibility.  I see that your script has the following
>line which I shall add:
>  xlObj.SetWarnings = false
>
>2) Path or working directory problems:
>I didn't think this would be an issue, as I pass all arguments on the
>command line, and refer to the template Excel spreadsheet with an absolute,
>not relative, filesystem path.
>
>My additional investigation yesterday led me to believe that my problem
>might be in how I construct the cmd string in this line:
>  Runtime.getRuntime( exec( cmd.toString() ) );
>
>These two links indicated this might be the problem:
>  http://java.sun.com/j2se/1.4.2/docs/api/   (See Process and Runtime
>classes)
>  http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html
>
>
>The first article specifically warns of issues in the Windows environment.
>
>Per the second article's suggestion, I switched to a different version of
>the overloaded exec() method.  Now using String[] cmdArray as argument
>instead of a long cmd String.   Also, I added StreamGobbler class and the
>constructs of the GoodWinExec.java example.  
>
>After making these changes, I had the same result as before:  It works in an
>unwrapped JBoss, but not the wrapped JBoss.
> 
>3) Making Excel visible.  Yes, I do reset this flag during debugging.  
>  objExcel.Visible = True
>Very fun to watch!
>   
>4) We tried changing the value of the wrapper.ntservice.interactive  flag
>but it did not have any apparent effect.
>
>5) VB On Error block.
>I also am not a VB expert nor have I done any registry hacking but I will
>definitely investigate this.
>
>Re: Sal's suggestions:
>1) I was unaware of Poi  http://jakarta.apache.org/poi/index.html
>Reading & writing Excel format files is useful but to leverage the Excel
>object model and to use Excel's computation engine, Excel has to be running.
>
>2) Java Mail API.  I use this elsewhere in the application for some separate
>functionality that generates PDF documents then emails them.  Works great!
>We considered reusing that functionality here but decided against PDF format
>in favor of Excel because of certain computation and tabular formatting
>where Excel is better suited.  The PDF generation runs in process and
>synchronously, blocking email until the PDF doc is written to the file
>system. 
>We also wanted the Excel process to run asynchronously and not have to block
>the email waiting on the file.  Since the Excel object model allows emailing
>natively, this seemed cleaner than writing a file and having another process
>reopen it to send it.  
>
>The Excel email capability works fine when exec()'ed from an unwrapped
>JBoss.
>  
>