wrapper-user — User issues for Wrapper. (Support questions, etc.)

Re: [Wrapper-user] Delaying console output redirection

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

Jason,
Are you meaning on UNIX? That is great idea. I often find myself
starting an application and then tailing the wrapper.log to make
sure it started normally.

I will think about how to do this.

Cheers,
Leif

Jason Resch wrote:
>
> I’d like to thank tanukisoftware for their wrapper, we find it quite 
> useful. The website reports “it does provide a number of properties to 
> configure how stdout and stderr output to the JVM console is handled”, 
> however after reviewing the online documentation I could not find the 
> exact feature I was looking for. My question to this list is whether 
> or not it is possible to accomplish the following using the wrapper:
>
> To start a daemon and allow it report any immediate errors (such as 
> problems in the configuration) directly to the console. Then, assuming 
> there were no immediate issues, daemonize and redirect output.
>
> I see several ways this could be done: signaling the wrapper to 
> redirect output, having the wrapper delay daemonizing for some fixed 
> period of time, or even simply not redirecting output at all, and then 
> have my application close stdout and stderr and use logging for the 
> rest of the application’s lifetime.
>
> Are any of the above methods possible?
>
> Thanks in advance,
>
> Jason Resch
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: 
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>   

[Wrapper-user] Delaying console output redirection

[Jason R. <jr...@cl...>]

I'd like to thank tanukisoftware for their wrapper, we find it quite
useful.  The website reports "it does provide a number of properties to
configure how stdout and stderr output to the JVM console is handled",
however after reviewing the online documentation I could not find the
exact feature I was looking for.  My question to this list is whether or
not it is possible to accomplish the following using the wrapper:

=20

To start a daemon and allow it report any immediate errors (such as
problems in the configuration) directly to the console.  Then, assuming
there were no immediate issues, daemonize and redirect output.

=20

I see several ways this could be done: signaling the wrapper to redirect
output, having the wrapper delay daemonizing for some fixed period of
time, or even simply not redirecting output at all, and then have my
application close stdout and stderr and use logging for the rest of the
application's lifetime.

=20

Are any of the above methods possible?

=20

Thanks in advance,

=20

Jason Resch

=20

Re: [Wrapper-user] conflict between wrapper and libjmp

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

Jeff,
The Wrapper simply launches the JVM process.  I have never seen any
cases where the Wrapper actually affected the way the JVM operated.
This is most likely a problem with the parameters used to launch the
JVM.

Try setting the following:
wrapper.java.command.loglevel=INFO
This will cause the full java command line to be output to the log file.
Copy that directly to the command line, removing the -Dwrapper.key=XXXX
parameter and run it directly.   If you also remove the libwrapper.so file
from the library path, you will be operating in a mode almost identical to
the case where the wrapper is not in the equation.  You will still be using
the WrapperManager class, but that will be 100% if the native library has
been removed.

Cheers,
Leif

Jeff Greif wrote:
> We are running JBoss under control of the wrapper on Linux with java 
> 1.5, where it works fine. 
>
> When we try to add a jvm profiling option in wrapper.conf of the form
>
> wrapperjava.additional.7=-Xrunjmp:noods,nomonitors,dumpdir=/home/xxx/profiling-results,dumptimer=1000
>
> the java process starts using many times more memory than before during 
> the application startup and becomes swap-bound.  The jvm is trying to 
> use 2-3x the memory specified in the -Xmx property.  We have not yet 
> determined where that memory use is occurring, but wonder if anyone has 
> seen issues combining the wrapper native library with libjmp.
>
> Jeff
>   

[Wrapper-user] conflict between wrapper and libjmp

[Jeff G. <jg...@we...>]

We are running JBoss under control of the wrapper on Linux with java 
1.5, where it works fine. 

When we try to add a jvm profiling option in wrapper.conf of the form

wrapperjava.additional.7=-Xrunjmp:noods,nomonitors,dumpdir=/home/xxx/profiling-results,dumptimer=1000

the java process starts using many times more memory than before during 
the application startup and becomes swap-bound.  The jvm is trying to 
use 2-3x the memory specified in the -Xmx property.  We have not yet 
determined where that memory use is occurring, but wonder if anyone has 
seen issues combining the wrapper native library with libjmp.

Jeff

Re: [Wrapper-user] 32 bit wrapper with a 64 bit jvm

[Chris <ch...@hm...>]

The 64bit linux version has been out for ages. It's just the windows one 
you need to wait for.

HTH
Chris

Markus Schlegel wrote:
> When you use the 32-bit Wrapper with the 64-it VM, you get a Log-Message 
> like "wrappermanager could not load dll xy..".
> Since the wrapper could not load this dll (because the dll is 32-bit), 
> it will not be able to interact with the OS.
> 
> Try this:
> - start your process when you are logged on, then log out.
> --> Your service stops working on logout.
> 
> You really have to use the 64-bit version, which is coming (hopefully 
> ;-) by the end of the year.
> 
> Markus
> 
> 2007/12/4, Cory Riddell <cri...@th... <mailto:cri...@th...>>:
> 
>     I have a couple of questions about 64 and 32 bit wrappers, for
>     Windows & Linux.
> 
>     On a 64 bit OS, you can run a 64 bit or a 32 bit JVM. Does the
>     wrapper need to match the JVM (32 or 64 bits) or the OS (64 bits)?  In
>     particular, will the 32 bit linux wrapper run on a 64-bit linux box?
> 
>     We've done some testing here and it seems like things mostly work
>     when mixing the 32 bit wrapper with a 64 bit JVM. On Windows we don't
>     really notice any problems, although we haven't tested very
>     extensively. On Linux we see a message about the 32-64 bit word width
>     mismatch, but things do seem to start up. Can you explain what's going
>     on? Is it actually working or is there a major problem lurking here?
> 
>     cory
> 
>     -------------------------------------------------------------------------
>     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
>     <http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4>
>     _______________________________________________
>     Wrapper-user mailing list
>     Wra...@li...
>     <mailto:Wra...@li...>
>     https://lists.sourceforge.net/lists/listinfo/wrapper-user
> 
> 
> 
> This email was received from the INTERNET and scanned by the Government 
> Secure Intranet anti-virus service supplied by Cable&Wireless in 
> partnership with MessageLabs. (CCTM Certificate Number 2007/11/0032.) In 
> case of problems, please call your organisation’s IT Helpdesk.
> Communications via the GSi may be automatically logged, monitored and/or 
> recorded for legal purposes.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

-- 
Chris
HMGCC

The information contained in this message (and any attachments) may
be confidential and is intended for the sole use of the named addressee.
Access, copying, alteration or re-use of the e-mail by anyone other
than the intended recipient is unauthorised. If you are not the intended
recipient please advise the sender immediately by returning the e-mail
and deleting it from your system.

This information may be exempt from disclosure under Freedom Of Information 
Act 2000 and may be subject to exemption under other UK information 
legislation. Refer disclosure requests to the Information Officer.


The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless in partnership with MessageLabs. (CCTM Certificate Number 2007/11/0032.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

Re: [Wrapper-user] 32 bit wrapper with a 64 bit jvm

[Markus S. <sc...@gm...>]

When you use the 32-bit Wrapper with the 64-it VM, you get a Log-Message
like "wrappermanager could not load dll xy..".
Since the wrapper could not load this dll (because the dll is 32-bit), it
will not be able to interact with the OS.

Try this:
- start your process when you are logged on, then log out.
--> Your service stops working on logout.

You really have to use the 64-bit version, which is coming (hopefully ;-) by
the end of the year.

Markus

2007/12/4, Cory Riddell <cri...@th...>:
>
> I have a couple of questions about 64 and 32 bit wrappers, for Windows &
> Linux.
>
> On a 64 bit OS, you can run a 64 bit or a 32 bit JVM. Does the
> wrapper need to match the JVM (32 or 64 bits) or the OS (64 bits)?  In
> particular, will the 32 bit linux wrapper run on a 64-bit linux box?
>
> We've done some testing here and it seems like things mostly work
> when mixing the 32 bit wrapper with a 64 bit JVM. On Windows we don't
> really notice any problems, although we haven't tested very
> extensively. On Linux we see a message about the 32-64 bit word width
> mismatch, but things do seem to start up. Can you explain what's going
> on? Is it actually working or is there a major problem lurking here?
>
> cory
>
> -------------------------------------------------------------------------
> 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
>

[Wrapper-user] 32 bit wrapper with a 64 bit jvm

[Cory R. <cri...@th...>]

I have a couple of questions about 64 and 32 bit wrappers, for Windows & Linux.

 On a 64 bit OS, you can run a 64 bit or a 32 bit JVM. Does the
wrapper need to match the JVM (32 or 64 bits) or the OS (64 bits)?  In
particular, will the 32 bit linux wrapper run on a 64-bit linux box?

 We've done some testing here and it seems like things mostly work
when mixing the 32 bit wrapper with a 64 bit JVM. On Windows we don't
really notice any problems, although we haven't tested very
extensively. On Linux we see a message about the 32-64 bit word width
mismatch, but things do seem to start up. Can you explain what's going
on? Is it actually working or is there a major problem lurking here?

cory

Re: [Wrapper-user] Mysterious Stream of -> Chars...

[Kit P. <fel...@bl...>]

Thanks Leif.  I found the problem...just capturing here for posterity.

Felix provides a command line/terminal interface in the form of OSGi  
bundles called shell and shell-tui.  When running in console mode  
these maintain their functionality allowing user input to the  
console.  But, when launching via the wrapper in daemon mode that  
functionality goes crazy.  Not starting those bundles allows Felix to  
run with no problems.

Kit

On Dec 3, 2007, at 9:55 AM, Leif Mortenson wrote:

> Kit,
> That output is mixed in with the other output of your application.
> The Wrapper appears to be logging it correctly.   I think that is
> coming from the application running within the Wrapper.  I would
> try doing a search in that code for "->" and see under which
> conditions that would happen.
>
> Cheers,
> Leif
>
> Kit Plummer wrote:
>> Here's the log file output.  First is the output from CONSOLE mode -
>> no problems.  Then, when I try to start as a DAEMON...it starts
>> chunkin'.
>>
>> http://pastebin.com/f35914f49
>>
>> Kit
>>
>>
>> On Dec 1, 2007, at 2:31 AM, Leif Mortenson wrote:
>>
>>
>>> Kit,
>>> If an application writes an updating status repeatedly over the same
>>> line the wrapper will output lots of lines out put due to the way  
>>> the
>>> logging works.  But that looks like a different issue than what you
>>> are seeing.
>>>
>>> At any rate, that is not coming from the wrapper itself.  What does
>>> the log file look like? Including timestamps?
>>>
>>> Cheers,
>>> Leif
>>>
>>> Kit Plummer wrote:
>>>
>>>> ...when running as a server, but not console.  Anyone see this?  My
>>>> log file files up very rapidly with:
>>>>
>>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -
>>>>
>>>>> -
>>>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> - 
>>>>> > -
>>>>> -> -> -> -> -> -> -> -> ->
>>>>>
>>>> I'm wrapping Felix (OSGi) framework.
>>>>
>>>> Thanks.
>>>> Kit
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>> 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
>>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
>
> -------------------------------------------------------------------------
> 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

Re: [Wrapper-user] Mysterious Stream of -> Chars...

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

Kit,
That output is mixed in with the other output of your application.
The Wrapper appears to be logging it correctly.   I think that is
coming from the application running within the Wrapper.  I would
try doing a search in that code for "->" and see under which
conditions that would happen.

Cheers,
Leif

Kit Plummer wrote:
> Here's the log file output.  First is the output from CONSOLE mode -  
> no problems.  Then, when I try to start as a DAEMON...it starts  
> chunkin'.
>
> http://pastebin.com/f35914f49
>
> Kit
>
>
> On Dec 1, 2007, at 2:31 AM, Leif Mortenson wrote:
>
>   
>> Kit,
>> If an application writes an updating status repeatedly over the same
>> line the wrapper will output lots of lines out put due to the way the
>> logging works.  But that looks like a different issue than what you
>> are seeing.
>>
>> At any rate, that is not coming from the wrapper itself.  What does
>> the log file look like? Including timestamps?
>>
>> Cheers,
>> Leif
>>
>> Kit Plummer wrote:
>>     
>>> ...when running as a server, but not console.  Anyone see this?  My
>>> log file files up very rapidly with:
>>>
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> - 
>>>       
>>>> -
>>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -
>>>> -> -> -> -> -> -> -> -> ->
>>>>         
>>> I'm wrapping Felix (OSGi) framework.
>>>
>>> Thanks.
>>> Kit
>>>
>>>       
>> -------------------------------------------------------------------------
>> 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
>>     
>
>
> -------------------------------------------------------------------------
> 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
>
>   

Re: [Wrapper-user] Mysterious Stream of -> Chars...

[Kit P. <fel...@bl...>]

Here's the log file output.  First is the output from CONSOLE mode -  
no problems.  Then, when I try to start as a DAEMON...it starts  
chunkin'.

http://pastebin.com/f35914f49

Kit


On Dec 1, 2007, at 2:31 AM, Leif Mortenson wrote:

> Kit,
> If an application writes an updating status repeatedly over the same
> line the wrapper will output lots of lines out put due to the way the
> logging works.  But that looks like a different issue than what you
> are seeing.
>
> At any rate, that is not coming from the wrapper itself.  What does
> the log file look like? Including timestamps?
>
> Cheers,
> Leif
>
> Kit Plummer wrote:
>> ...when running as a server, but not console.  Anyone see this?  My
>> log file files up very rapidly with:
>>
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> - 
>> > -
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -
>>> -> -> -> -> -> -> -> -> ->
>>
>> I'm wrapping Felix (OSGi) framework.
>>
>> Thanks.
>> Kit
>>
>
>
> -------------------------------------------------------------------------
> 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

Re: [Wrapper-user] AS400, i5OS

[Nicolas V. <ni...@va...>]

Le 30 nov. 07 =E0 19:58, Robert DiFalco a =E9crit :

> Has anyone ported the wrapper to AS400 or know of an equivalent
> functionality?

I have some iSeries under AS400. But still too novice on that =20
architectures.
I'm just submitting jobs via CL scripts and supervise that they are =20
still running.

Regards.

Nicolas Varney=

Re: [Wrapper-user] Mysterious Stream of -> Chars...

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

Kit,
If an application writes an updating status repeatedly over the same
line the wrapper will output lots of lines out put due to the way the
logging works.  But that looks like a different issue than what you
are seeing.

At any rate, that is not coming from the wrapper itself.  What does
the log file look like? Including timestamps?

Cheers,
Leif

Kit Plummer wrote:
> ...when running as a server, but not console.  Anyone see this?  My  
> log file files up very rapidly with:
>
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> - 
>  > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> - 
>  > -> -> -> -> -> -> -> -> ->
>
> I'm wrapping Felix (OSGi) framework.
>
> Thanks.
> Kit
>   

[Wrapper-user] Mysterious Stream of -> Chars...

[Kit P. <fel...@bl...>]

...when running as a server, but not console.  Anyone see this?  My  
log file files up very rapidly with:

-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> - 
 > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> - 
 > -> -> -> -> -> -> -> -> ->

I'm wrapping Felix (OSGi) framework.

Thanks.
Kit

[Wrapper-user] AS400, i5OS

[Robert D. <rdi...@tr...>]

Has anyone ported the wrapper to AS400 or know of an equivalent
functionality?

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

[Adrian M. <ama...@ge...>]

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
>   

Re: [Wrapper-user] 64 bit JVM, 32 bit wrapper

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

Cory,
On Windows, you can use the 32-bit Wrapper on a 64-bit machine, but
if you are using a 64-bit JVM, you must be using a 64-bit version of the
Wrapper.

The 64-bit Wrapper has not yet been released.  I am working to get it
out by the end of the year as a lot of people have been requesting it
lately.

Cheers,
Leif

Cory Riddell wrote:
> Can somebody tell me what the differences are between a 32-bit version 
> of the wrapper and a 64-bit version. Since the wrapped application is 
> running in a different process (the JVM), can we use the 32-bit 
> wrapper on a 64 bit machine with a 64 bit JVM? Is there some kind of 
> impedance mismatch problem with using a 32-bit wrapper and a 64-bit JVM?
>
> Thanks,
> Cory
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>   

Re: [Wrapper-user] ^^C not working sometimes

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

Tom,
Sorry I had forgotten to check in that filePart fix on Windows.  Its
in now.  I made all the changes originally on Linux then found that
when building on Windows.  I'll check the 64 bit build today.

Cheers,
Leif

Tom Saulpaugh wrote:
> Leif,
>
> I did an update:
>
> D:\JavaServiceWrapperTrunk\wrapper\wrapper>svn update
> U    src\c\wrappereventloop.c
> U    src\c\wrapper.c
> U    src\c\property.c
> U    default.properties
> U    doc\revisions.txt
> Updated to revision 1380.
>
> and got this error after doing these 64-bit build commands:
>
> D:\JavaServiceWrapperTrunk\wrapper\wrapper>build64.bat clean D:\JavaServiceWrapperTrunk\wrapper\wrapper>build64.bat
>
> wrapper.c
> wrapper.c(312) : error C2065: 'filePart' : undeclared identifier
> wrapper.c(312) : warning C4090: 'function' : different '__ptr64' qualifiers
> NMAKE :  U1077: '"D:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\
> cl.EXE"' : return code '0x2'
> Stop.
>
> BUILD FAILED
> D:\repositories\metalincsmodules\Wrapper\build.xml:514: exec returned: 2
>
> Total time: 4 seconds
> D:\repositories\metalincsmodules\Wrapper>
>
> I'll try and build the 32-bit version.
>
> Thanks,
>
> Tom
>
>
>
> -----Original Message-----
> From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson
> Sent: Wednesday, November 28, 2007 11:18 AM
> To: wra...@li...
> Subject: Re: [Wrapper-user] ^^C not working sometimes
>
> Tom,
> I have gotten this problem fixed in the SVN trunk code.  It was a
> problem I introduced by "cleaning up" the state engine for the 3.3.0
> release.  It had not been released.
>
> Please give it a try and let me know if you find any other problems.
>
> Cheers,
> Leif
>
> Tom Saulpaugh wrote:
>   
>> The previous version was 3.2.3.
>> We are now using version 3.3.0-b
>>
>> Tom
>>
>> -----Original Message-----
>> From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson
>> Sent: Tuesday, November 20, 2007 7:26 PM
>> To: wra...@li...
>> Subject: Re: [Wrapper-user] ^^C not working sometimes
>>
>> Tom,
>> I agree, that something is not working correctly.   You said with the
>> previous
>> version "2.3" it was working.  Do you mean "3.2.3"?  What version are you
>> using now?
>>
>> Cheers,
>> Leif
>>
>> Tom Saulpaugh wrote:
>>
>>     
>>> Leif,
>>>
>>> Here is the log during the double ctl-c.
>>>
>>> It takes 6 seconds to shutdown the JVM starting at
>>>
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Signal trapped.  Details:
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 |   signal number=2 (SIGINT), source="the kernel"
>>> STATUS | wrapper  | main    | 2007/11/20 13:58:36 | INT trapped.  Shutting down.
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | wrapperStopProcess(0) called.
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Sending stop signal to JVM
>>> DEBUG  | wrapperp | main    | 2007/11/20 13:58:36 | send a packet STOP : NULL
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Signal trapped.  Details:
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 |   signal number=2 (SIGINT), source="the kernel"
>>> STATUS | wrapper  | main    | 2007/11/20 13:58:36 | INT trapped.  Forcing immediate shutdown.
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Received a packet STOP :
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Thread, Wrapper-Connection, handling the shutdown process.
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: calling listener.stop()
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Waiting for WrapperListener.stop runner thread to complete.
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Processing control event(WRAPPER_CTRL_C_EVENT)
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: WrapperManager.stop(0) called by thread: Wrapper-Control-Event-Monitor
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Thread, Wrapper-Control-Event-Monitor, waiting for the JVM to exit.
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: WrapperListener.stop runner thread started.
>>>
>>>
>>> < OUR JVM SHUTDOWN PROCESSING HERE>
>>> .
>>> .
>>> .
>>> < OUR JVM SHUTDOWN PROCESSING HERE>
>>>
>>>
>>> and ending at:
>>>
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: WrapperListener.stop runner thread stopped.
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: returned from listener.stop() -> 0
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: shutdownJVM(0) Thread:Wrapper-Connection
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: Send a packet STOPPED : 0
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: Closing socket.
>>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: calling System.exit(0)
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | JVM exited normally.
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | Signal trapped.  Details:
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 |   signal number=17 (SIGCHLD), source="unknown"
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | Received SIGCHLD, checking JVM process status.
>>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | JVM process exited with a code of 0, leaving the wrapper exit code set to 0.
>>> STATUS | wrapper  | main    | 2007/11/20 13:58:42 | <-- Wrapper Stopped
>>>
>>> It seems like that even when the wrapper says it is forcing an immediate shutdown, it is waiting for the JVM to finish and during that time our code is doing its shutdown processing, which takes 6 seconds in this case.
>>>
>>> I'm confused regarding the notion of "immediate".  What is an immediate shutdown?  How is it different than kill -9 JVM_PID?
>>>
>>> With the previous wrapper (2.3) this never happened.  Did anything change that would affect immediate shutdown?
>>>
>>> Thanks for your help,
>>>
>>> Tom
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson
>>> Sent: Monday, November 19, 2007 6:28 PM
>>> To: wra...@li...
>>> Subject: Re: [Wrapper-user] ^^C not working sometimes
>>>
>>> Tom,
>>> There used to be a bug where the Wrapper would sometimes mistake
>>> a single CTRL-C event as two and kill the JVM.  But I have never seen
>>> what you are seeing.
>>>
>>> Could you try to reproduce this with wrapper.debug=true enabled?
>>>
>>> How long apart are the two CTRL-C events?   Are you seeing
>>> messages in the log for both of them?
>>>
>>> Cheers,
>>> Leif
>>>
>>> Tom Saulpaugh wrote:
>>>
>>>
>>>       
>>>> Has anyone noticed that double cntrl-c  doesn't always kill the JVM?
>>>>
>>>> I have seen this on linux and windows.
>>>>
>>>> Is there a fix for this?
>>>>
>>>> It seems to happen when the JVM is under heavy load.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> -------------------------------------------------------------------------
>>>> 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
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>
>> -------------------------------------------------------------------------
>> 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
>
> -------------------------------------------------------------------------
> 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
>
>   

[Wrapper-user] 64 bit JVM, 32 bit wrapper

[Cory R. <cri...@th...>]

Can somebody tell me what the differences are between a 32-bit version of
the wrapper and a 64-bit version. Since the wrapped application is running
in a different process (the JVM), can we use the 32-bit wrapper on a 64 bit
machine with a 64 bit JVM? Is there some kind of impedance mismatch problem
with using a 32-bit wrapper and a 64-bit JVM?

Thanks,
Cory

Re: [Wrapper-user] ^^C not working sometimes

[Tom S. <Tom...@Me...>]

Leif,

When I try and build the 32-bit wrapper, I get:

        cl /D "WIN32" /D "NDEBUG"  /FD /EHsc /MT /Zp4 /W3 /nologo /c /Zi /e=
rrorR
eport:prompt /D "_CRT_SECURE_NO_DEPRECATE" /O2 /GL /D "_CONSOLE" /Wp64 /Fo"=
wrapp
er32_VC8__Win32_Release\\" /Fd"wrapper32_VC8__Win32_Release\\" wrapper.c
wrapper.c
wrapper.c(312) : error C2065: 'filePart' : undeclared identifier
wrapper.c(312) : warning C4047: 'function' : 'LPSTR *' differs in levels of=
 indi
rection from 'int *__w64 '
wrapper.c(312) : warning C4024: 'GetFullPathNameA' : different types for fo=
rmal
and actual parameter 4
NMAKE :  U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\cl.EXE"=
' : r
eturn code '0x2'
Stop.

BUILD FAILED
D:\repositories\metalincsmodules\Wrapper\build.xml:514: exec returned: 2

Total time: 7 seconds
D:\repositories\metalincsmodules\Wrapper>

Tom

-----Original Message-----
From: wra...@li... [mailto:wrapper-user-bounc=
es...@li...] On Behalf Of Tom Saulpaugh
Sent: Wednesday, November 28, 2007 1:19 PM
To: 'wra...@li...'
Subject: Re: [Wrapper-user] ^^C not working sometimes

Leif,

I did an update:

D:\JavaServiceWrapperTrunk\wrapper\wrapper>svn update
U    src\c\wrappereventloop.c
U    src\c\wrapper.c
U    src\c\property.c
U    default.properties
U    doc\revisions.txt
Updated to revision 1380.

and got this error after doing these 64-bit build commands:

D:\JavaServiceWrapperTrunk\wrapper\wrapper>build64.bat clean D:\JavaService=
WrapperTrunk\wrapper\wrapper>build64.bat

wrapper.c
wrapper.c(312) : error C2065: 'filePart' : undeclared identifier
wrapper.c(312) : warning C4090: 'function' : different '__ptr64' qualifiers
NMAKE :  U1077: '"D:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\a=
md64\
cl.EXE"' : return code '0x2'
Stop.

BUILD FAILED
D:\repositories\metalincsmodules\Wrapper\build.xml:514: exec returned: 2

Total time: 4 seconds
D:\repositories\metalincsmodules\Wrapper>

I'll try and build the 32-bit version.

Thanks,

Tom



-----Original Message-----
From: wra...@li... [mailto:wrapper-user-bounc=
es...@li...] On Behalf Of Leif Mortenson
Sent: Wednesday, November 28, 2007 11:18 AM
To: wra...@li...
Subject: Re: [Wrapper-user] ^^C not working sometimes

Tom,
I have gotten this problem fixed in the SVN trunk code.  It was a
problem I introduced by "cleaning up" the state engine for the 3.3.0
release.  It had not been released.

Please give it a try and let me know if you find any other problems.

Cheers,
Leif

Tom Saulpaugh wrote:
> The previous version was 3.2.3.
> We are now using version 3.3.0-b
>
> Tom
>
> -----Original Message-----
> From: wra...@li... [mailto:wrapper-user-bou=
nc...@li...] On Behalf Of Leif Mortenson
> Sent: Tuesday, November 20, 2007 7:26 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] ^^C not working sometimes
>
> Tom,
> I agree, that something is not working correctly.   You said with the
> previous
> version "2.3" it was working.  Do you mean "3.2.3"?  What version are you
> using now?
>
> Cheers,
> Leif
>
> Tom Saulpaugh wrote:
>
>> Leif,
>>
>> Here is the log during the double ctl-c.
>>
>> It takes 6 seconds to shutdown the JVM starting at
>>
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Signal trapped.  Det=
ails:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 |   signal number=3D2 =
(SIGINT), source=3D"the kernel"
>> STATUS | wrapper  | main    | 2007/11/20 13:58:36 | INT trapped.  Shutti=
ng down.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | wrapperStopProcess(0=
) called.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Sending stop signal =
to JVM
>> DEBUG  | wrapperp | main    | 2007/11/20 13:58:36 | send a packet STOP :=
 NULL
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Signal trapped.  Det=
ails:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 |   signal number=3D2 =
(SIGINT), source=3D"the kernel"
>> STATUS | wrapper  | main    | 2007/11/20 13:58:36 | INT trapped.  Forcin=
g immediate shutdown.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Received a packet STOP :
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Thread, Wrapper-Connection, handling the shutdown process.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: calling listener.stop()
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Waiting for WrapperListener.stop runner thread to complete.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Processing control event(WRAPPER_CTRL_C_EVENT)
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: WrapperManager.stop(0) called by thread: Wrapper-Control-Event-Monitor
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Thread, Wrapper-Control-Event-Monitor, waiting for the JVM to exit.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: WrapperListener.stop runner thread started.
>>
>>
>> < OUR JVM SHUTDOWN PROCESSING HERE>
>> .
>> .
>> .
>> < OUR JVM SHUTDOWN PROCESSING HERE>
>>
>>
>> and ending at:
>>
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: WrapperListener.stop runner thread stopped.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: returned from listener.stop() -> 0
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: shutdownJVM(0) Thread:Wrapper-Connection
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: Send a packet STOPPED : 0
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: Closing socket.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: calling System.exit(0)
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | JVM exited normally.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | Signal trapped.  Det=
ails:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 |   signal number=3D17=
 (SIGCHLD), source=3D"unknown"
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | Received SIGCHLD, ch=
ecking JVM process status.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | JVM process exited w=
ith a code of 0, leaving the wrapper exit code set to 0.
>> STATUS | wrapper  | main    | 2007/11/20 13:58:42 | <-- Wrapper Stopped
>>
>> It seems like that even when the wrapper says it is forcing an immediate=
 shutdown, it is waiting for the JVM to finish and during that time our cod=
e is doing its shutdown processing, which takes 6 seconds in this case.
>>
>> I'm confused regarding the notion of "immediate".  What is an immediate =
shutdown?  How is it different than kill -9 JVM_PID?
>>
>> With the previous wrapper (2.3) this never happened.  Did anything chang=
e that would affect immediate shutdown?
>>
>> Thanks for your help,
>>
>> Tom
>>
>>
>>
>> -----Original Message-----
>> From: wra...@li... [mailto:wrapper-user-bo=
un...@li...] On Behalf Of Leif Mortenson
>> Sent: Monday, November 19, 2007 6:28 PM
>> To: wra...@li...
>> Subject: Re: [Wrapper-user] ^^C not working sometimes
>>
>> Tom,
>> There used to be a bug where the Wrapper would sometimes mistake
>> a single CTRL-C event as two and kill the JVM.  But I have never seen
>> what you are seeing.
>>
>> Could you try to reproduce this with wrapper.debug=3Dtrue enabled?
>>
>> How long apart are the two CTRL-C events?   Are you seeing
>> messages in the log for both of them?
>>
>> Cheers,
>> Leif
>>
>> Tom Saulpaugh wrote:
>>
>>
>>> Has anyone noticed that double cntrl-c  doesn't always kill the JVM?
>>>
>>> I have seen this on linux and windows.
>>>
>>> Is there a fix for this?
>>>
>>> It seems to happen when the JVM is under heavy load.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>
>>> -----------------------------------------------------------------------=
-
>>>
>>> -----------------------------------------------------------------------=
--
>>> 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
>>
>> ------------------------------------------------------------------------=
-
>> 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
>
> -------------------------------------------------------------------------
> 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

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

Re: [Wrapper-user] ^^C not working sometimes

[Tom S. <Tom...@Me...>]

Leif,

I did an update:

D:\JavaServiceWrapperTrunk\wrapper\wrapper>svn update
U    src\c\wrappereventloop.c
U    src\c\wrapper.c
U    src\c\property.c
U    default.properties
U    doc\revisions.txt
Updated to revision 1380.

and got this error after doing these 64-bit build commands:

D:\JavaServiceWrapperTrunk\wrapper\wrapper>build64.bat clean D:\JavaService=
WrapperTrunk\wrapper\wrapper>build64.bat

wrapper.c
wrapper.c(312) : error C2065: 'filePart' : undeclared identifier
wrapper.c(312) : warning C4090: 'function' : different '__ptr64' qualifiers
NMAKE :  U1077: '"D:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\a=
md64\
cl.EXE"' : return code '0x2'
Stop.

BUILD FAILED
D:\repositories\metalincsmodules\Wrapper\build.xml:514: exec returned: 2

Total time: 4 seconds
D:\repositories\metalincsmodules\Wrapper>

I'll try and build the 32-bit version.

Thanks,

Tom



-----Original Message-----
From: wra...@li... [mailto:wrapper-user-bounc=
es...@li...] On Behalf Of Leif Mortenson
Sent: Wednesday, November 28, 2007 11:18 AM
To: wra...@li...
Subject: Re: [Wrapper-user] ^^C not working sometimes

Tom,
I have gotten this problem fixed in the SVN trunk code.  It was a
problem I introduced by "cleaning up" the state engine for the 3.3.0
release.  It had not been released.

Please give it a try and let me know if you find any other problems.

Cheers,
Leif

Tom Saulpaugh wrote:
> The previous version was 3.2.3.
> We are now using version 3.3.0-b
>
> Tom
>
> -----Original Message-----
> From: wra...@li... [mailto:wrapper-user-bou=
nc...@li...] On Behalf Of Leif Mortenson
> Sent: Tuesday, November 20, 2007 7:26 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] ^^C not working sometimes
>
> Tom,
> I agree, that something is not working correctly.   You said with the
> previous
> version "2.3" it was working.  Do you mean "3.2.3"?  What version are you
> using now?
>
> Cheers,
> Leif
>
> Tom Saulpaugh wrote:
>
>> Leif,
>>
>> Here is the log during the double ctl-c.
>>
>> It takes 6 seconds to shutdown the JVM starting at
>>
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Signal trapped.  Det=
ails:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 |   signal number=3D2 =
(SIGINT), source=3D"the kernel"
>> STATUS | wrapper  | main    | 2007/11/20 13:58:36 | INT trapped.  Shutti=
ng down.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | wrapperStopProcess(0=
) called.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Sending stop signal =
to JVM
>> DEBUG  | wrapperp | main    | 2007/11/20 13:58:36 | send a packet STOP :=
 NULL
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Signal trapped.  Det=
ails:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 |   signal number=3D2 =
(SIGINT), source=3D"the kernel"
>> STATUS | wrapper  | main    | 2007/11/20 13:58:36 | INT trapped.  Forcin=
g immediate shutdown.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Received a packet STOP :
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Thread, Wrapper-Connection, handling the shutdown process.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: calling listener.stop()
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Waiting for WrapperListener.stop runner thread to complete.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Processing control event(WRAPPER_CTRL_C_EVENT)
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: WrapperManager.stop(0) called by thread: Wrapper-Control-Event-Monitor
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: Thread, Wrapper-Control-Event-Monitor, waiting for the JVM to exit.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug=
: WrapperListener.stop runner thread started.
>>
>>
>> < OUR JVM SHUTDOWN PROCESSING HERE>
>> .
>> .
>> .
>> < OUR JVM SHUTDOWN PROCESSING HERE>
>>
>>
>> and ending at:
>>
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: WrapperListener.stop runner thread stopped.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: returned from listener.stop() -> 0
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: shutdownJVM(0) Thread:Wrapper-Connection
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: Send a packet STOPPED : 0
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: Closing socket.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug=
: calling System.exit(0)
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | JVM exited normally.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | Signal trapped.  Det=
ails:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 |   signal number=3D17=
 (SIGCHLD), source=3D"unknown"
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | Received SIGCHLD, ch=
ecking JVM process status.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | JVM process exited w=
ith a code of 0, leaving the wrapper exit code set to 0.
>> STATUS | wrapper  | main    | 2007/11/20 13:58:42 | <-- Wrapper Stopped
>>
>> It seems like that even when the wrapper says it is forcing an immediate=
 shutdown, it is waiting for the JVM to finish and during that time our cod=
e is doing its shutdown processing, which takes 6 seconds in this case.
>>
>> I'm confused regarding the notion of "immediate".  What is an immediate =
shutdown?  How is it different than kill -9 JVM_PID?
>>
>> With the previous wrapper (2.3) this never happened.  Did anything chang=
e that would affect immediate shutdown?
>>
>> Thanks for your help,
>>
>> Tom
>>
>>
>>
>> -----Original Message-----
>> From: wra...@li... [mailto:wrapper-user-bo=
un...@li...] On Behalf Of Leif Mortenson
>> Sent: Monday, November 19, 2007 6:28 PM
>> To: wra...@li...
>> Subject: Re: [Wrapper-user] ^^C not working sometimes
>>
>> Tom,
>> There used to be a bug where the Wrapper would sometimes mistake
>> a single CTRL-C event as two and kill the JVM.  But I have never seen
>> what you are seeing.
>>
>> Could you try to reproduce this with wrapper.debug=3Dtrue enabled?
>>
>> How long apart are the two CTRL-C events?   Are you seeing
>> messages in the log for both of them?
>>
>> Cheers,
>> Leif
>>
>> Tom Saulpaugh wrote:
>>
>>
>>> Has anyone noticed that double cntrl-c  doesn't always kill the JVM?
>>>
>>> I have seen this on linux and windows.
>>>
>>> Is there a fix for this?
>>>
>>> It seems to happen when the JVM is under heavy load.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>
>>> -----------------------------------------------------------------------=
-
>>>
>>> -----------------------------------------------------------------------=
--
>>> 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
>>
>> ------------------------------------------------------------------------=
-
>> 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
>
> -------------------------------------------------------------------------
> 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

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

Re: [Wrapper-user] ^^C not working sometimes

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

Tom,
I have gotten this problem fixed in the SVN trunk code.  It was a
problem I introduced by "cleaning up" the state engine for the 3.3.0
release.  It had not been released.

Please give it a try and let me know if you find any other problems.

Cheers,
Leif

Tom Saulpaugh wrote:
> The previous version was 3.2.3.
> We are now using version 3.3.0-b
>
> Tom
>
> -----Original Message-----
> From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson
> Sent: Tuesday, November 20, 2007 7:26 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] ^^C not working sometimes
>
> Tom,
> I agree, that something is not working correctly.   You said with the
> previous
> version "2.3" it was working.  Do you mean "3.2.3"?  What version are you
> using now?
>
> Cheers,
> Leif
>
> Tom Saulpaugh wrote:
>   
>> Leif,
>>
>> Here is the log during the double ctl-c.
>>
>> It takes 6 seconds to shutdown the JVM starting at
>>
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Signal trapped.  Details:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 |   signal number=2 (SIGINT), source="the kernel"
>> STATUS | wrapper  | main    | 2007/11/20 13:58:36 | INT trapped.  Shutting down.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | wrapperStopProcess(0) called.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Sending stop signal to JVM
>> DEBUG  | wrapperp | main    | 2007/11/20 13:58:36 | send a packet STOP : NULL
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 | Signal trapped.  Details:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:36 |   signal number=2 (SIGINT), source="the kernel"
>> STATUS | wrapper  | main    | 2007/11/20 13:58:36 | INT trapped.  Forcing immediate shutdown.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Received a packet STOP :
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Thread, Wrapper-Connection, handling the shutdown process.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: calling listener.stop()
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Waiting for WrapperListener.stop runner thread to complete.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Processing control event(WRAPPER_CTRL_C_EVENT)
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: WrapperManager.stop(0) called by thread: Wrapper-Control-Event-Monitor
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: Thread, Wrapper-Control-Event-Monitor, waiting for the JVM to exit.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:36 | WrapperManager Debug: WrapperListener.stop runner thread started.
>>
>>
>> < OUR JVM SHUTDOWN PROCESSING HERE>
>> .
>> .
>> .
>> < OUR JVM SHUTDOWN PROCESSING HERE>
>>
>>
>> and ending at:
>>
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: WrapperListener.stop runner thread stopped.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: returned from listener.stop() -> 0
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: shutdownJVM(0) Thread:Wrapper-Connection
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: Send a packet STOPPED : 0
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: Closing socket.
>> INFO   | jvm 1    | main    | 2007/11/20 13:58:42 | WrapperManager Debug: calling System.exit(0)
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | JVM exited normally.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | Signal trapped.  Details:
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 |   signal number=17 (SIGCHLD), source="unknown"
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | Received SIGCHLD, checking JVM process status.
>> DEBUG  | wrapper  | main    | 2007/11/20 13:58:42 | JVM process exited with a code of 0, leaving the wrapper exit code set to 0.
>> STATUS | wrapper  | main    | 2007/11/20 13:58:42 | <-- Wrapper Stopped
>>
>> It seems like that even when the wrapper says it is forcing an immediate shutdown, it is waiting for the JVM to finish and during that time our code is doing its shutdown processing, which takes 6 seconds in this case.
>>
>> I'm confused regarding the notion of "immediate".  What is an immediate shutdown?  How is it different than kill -9 JVM_PID?
>>
>> With the previous wrapper (2.3) this never happened.  Did anything change that would affect immediate shutdown?
>>
>> Thanks for your help,
>>
>> Tom
>>
>>
>>
>> -----Original Message-----
>> From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson
>> Sent: Monday, November 19, 2007 6:28 PM
>> To: wra...@li...
>> Subject: Re: [Wrapper-user] ^^C not working sometimes
>>
>> Tom,
>> There used to be a bug where the Wrapper would sometimes mistake
>> a single CTRL-C event as two and kill the JVM.  But I have never seen
>> what you are seeing.
>>
>> Could you try to reproduce this with wrapper.debug=true enabled?
>>
>> How long apart are the two CTRL-C events?   Are you seeing
>> messages in the log for both of them?
>>
>> Cheers,
>> Leif
>>
>> Tom Saulpaugh wrote:
>>
>>     
>>> Has anyone noticed that double cntrl-c  doesn't always kill the JVM?
>>>
>>> I have seen this on linux and windows.
>>>
>>> Is there a fix for this?
>>>
>>> It seems to happen when the JVM is under heavy load.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>
>> -------------------------------------------------------------------------
>> 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
>
> -------------------------------------------------------------------------
> 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
>
>   

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

[<ama...@ge...>]

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
>   

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

[Gabriel J. <goj...@ya...>]

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/

[Wrapper-user] Runtime.exec() problem

[Adrian M. <ama...@ge...>]

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.