Re: [Wrapper-user] Runtime.exec() problem

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Many thanks Leif for your elaborate answer.

It's just like you say about the pipe between the processes. Now I have
2 threads dedicated to read from the .NET app's stdout and stderr, and
everything is working smoothly.

Just in case someone with the same problem comes browsing through the
mailing list archives, there is an excellent article describing this
issue at:

http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html

I was planning on mailing back when I got things completely figured out,
i.e., I still don't get why the 2nd app froze only when the 1st got
installed as a service; it should have frozen 'stand alone' too! And out
of curiosity I redirected stderr and stdout to some files, to see what
was filling the pipe, but these files turned out to be empty after I ran
the service... (I still need to check for errors in my code regarding this).

I have my hands full with a thousand things at the moment, but as soon
as I can I'll get back to you about whether the service could work by
simply adding 'start' to "cmd /c startup.bat > null". Furthermore, I can
tell you that "cmd /c startup.bat > null" didn't work because running
exec() of this line _does not redirect stdout_. The explanation for this
can be found in the article I mentioned before.

Thanks again for your time.

Regards.

Adrián.

Leif Mortenson wrote:
> Adrian,
> Most likely the differences you are seeing are being caused somehow
> by the lack of a console window when run as a service.  You can cause
> an invisible console window to be created by setting the following
> property in your configuration file:
>
> wrapper.request_thread_dump_on_failed_jvm_exit=TRUE
>
> My guess is that you will start seeing the same behavior as you do
> when running in console mode.
>
> Background on your problem.  If a thread writes to a pipe and that
> pipe is full, the write operation will block until the pipe has room for
> the latest message.  In your case,  the Java application was not reading
> from the output of the child process.  It took a little time for the pipe
> buffer to fill up, but once it did, the main thread of your .Net app
> started blocking and appeared to be frozen.  When you killed the
> Java process, Windows closed that end of the pipe and everything in
> the pipe got flushed to the bit bucket.  That allowed your .Net app
> to start flowing again.
>
> You mention that "cmd /c start startup.bat > null" is working,
> but that "cmd /c startup.bat > null" is not.  Is this only true after
> you started having your Java application read from Standard out?
>
> I would expect that the "start" case above would have worked even
> if your java app did not process the output.  This is because the
> "start" command is tell the OS to launch the startup.bat file with
> its own new console window.   The case without "start" would launch
> within the parent console window so it needs to be processed.
>
> As you are still seeing the problem, my guess is that you are currently
> only reading the stdout of the child process.  Make sure you are also
> reading any stderr output as well.  They would both cause blocking
> if full.
>
> Cheers,
> Leif
>
>
> Adrián Márques wrote:
>   
>> Many thanks Gabriel for your response. It was precisely this.
>>
>> I am still looking into it since I don't quite understand why the second 
>> app didn't freeze when the first was not run as a service. Also, when 
>> the exec argument is "cmd /c start startup.bat > null" everything works 
>> fine now, but using for instance "cmd /c startup.bat > null" has exactly 
>> the same problem as before. I'm checking out why, frankly I'm not 
>> familiar with windows commands.
>>
>> Thanks again for your prompt reply.
>>
>> Regards.
>>
>> Adrián.
>>
>> Gabriel Jurado escribió:
>>   
>>     
>>> Hello Adrian, 
>>> I had a similar problem, make sure that you are reading or at least discarding the output of your
>>> "executed" application, like the standard output and the error output of the process.
>>>
>>> Regards,
>>>
>>> G.J.
>>>
>>> --- Adrian Marques <ama...@ge...> escribió:
>>>
>>>   
>>>     
>>>       
>>>> Hello everyone,
>>>>
>>>> I have a Java application that uses Runtime.exec() to start another .NET
>>>> app. This works just fine when running my program 'standalone'.
>>>> The problem arises when I use the wrapper to install my Java app as a
>>>> service: Runtime.exec() executes ok, the .NET app is launched and it
>>>> seems to work without issues up to about one and a half / two minutes
>>>> into execution, where it freezes and is seen as 'not responding' by windows.
>>>>
>>>> I have browsed through the mailing lists archives and seen some problems
>>>> with exec() related to the access to network drives or error dialog
>>>> messages that are not displayed on screen, but I don't think any of this
>>>> applies to me. Of course I considered that the problem may be caused by
>>>> the .NET app running as SYSTEM, but (and I find this quite puzzling)
>>>> after the freeze if I stop the java service or just plain kill the java
>>>> process the .NET app resumes normal execution as if nothing had happened
>>>> and has no more problems.
>>>>
>>>> A couple more details:
>>>>
>>>> - My java app has no GUI; the .NET one does.
>>>> - The java service seems to keep running in normal fashion after the
>>>> .NET app hangs.
>>>> - (Don't know if this is relevant) The .NET app acts as client to some
>>>> web services. It invokes them some times without any apparent issues
>>>> before hanging.
>>>>
>>>> If anyone could point me in the right direction where to look regarding
>>>> this it would be greatly appreciated (I'm quite lost here).
>>>>
>>>> Many thanks.
>>>>
>>>> Adrián.
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Wrapper-user mailing list
>>>> Wra...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>>
>>>>     
>>>>       
>>>>         
>>>       Los referentes más importantes en compra/ venta de autos se juntaron:
>>> Demotores y Yahoo!
>>> Ahora comprar o vender tu auto es más fácil. Vistá ar.autos.yahoo.com/
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>   
>>>     
>>>       
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>   
>>     
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>   