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

[Leif M. <le...@ta...>]

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