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

Re: [Wrapper-user] JVM hang causes

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

Paul,

Paul Casanova wrote:

>The JVM for the main process of our application (-Xmx1600M) was restarted
>by the Java Service Wrapper today after pinging with no response from the
>JVM for 10 mintues (as configured).
>
>I can't for the life of me work out why it was hung though - there were no
>exceptions in either the JSW log file nor the application's log file.
>  
>
See more below, but if the JVM does lock up, there will usually not be 
any stack
traces or errors.  The display of such errors requires that the JVM 
still be running.

>Moreover, when the JSW tried to get a thread dump on exit, it failed.
>Here's a snippet from the log file:
>ERROR  | wrapper  | 2004/02/17 12:02:55 | JVM appears hung: Timed out
>waiting for signal from JVM.
>STATUS | wrapper  | 2004/02/17 12:02:55 | Dumping JVM state.
>DEBUG  | wrapper  | 2004/02/17 12:02:55 | Sending BREAK event to process
>group 336.
>ERROR  | wrapper  | 2004/02/17 12:02:55 | Unable to send BREAK event to JVM
>process.  Err(6 : The handle is invalid. (0x6))
>  
>
This is a bug that has been fixed in 3.1.0.   It was not previously 
possible to invoke a
thread dump on exit when running as an NT service due to the lack of a 
console.

http://sourceforge.net/tracker/index.php?func=detail&aid=831775&group_id=39428&atid=425187

Thread dumps invoked from within the JVM had always worked.

>ERROR  | wrapper  | 2004/02/17 12:02:58 | Java Virtual Machine did not exit
>on request, terminated
>
>Before this was just 10 minutes of pinging without response from the JVM.
>I know that noone can tell me what happened, but does anyone have some
>ideas on where to start looking (ie make the haystack smaller so that the
>needle is more obvious!).
>  
>
If you were able to see pings being sent to the JVM but no replies then 
the problem is
most likely a problem with the JVM.
During those 10 minutes, do you know whether or not your application was
responsive?
Do you know what the CPU usage of the machine was during this time?

If your app was unresponsive and CPU usage was low then the problem was most
likely that the JVM froze up, and the Wrapper did its job.

Are you sure that all 1600MB of the JVM is able to fit entirely in real 
memory?  If
the memory is being swapped to disk it is possible that the JVM was simply
unresponsive as it was being swapped.   I have never run an app quite 
this large,
but I have seen a JVM freeze up for up to 2 minutes as it attempts to do 
a GC
sweep in cases where there is not enough memory.  That was for a JVM using
around 200MB.  So It seems entirely possible that such a sweep could take 10
minutes for 1600MB.  This will happen even without using the Wrapper.

Are you able to reproduce this?  If so, try running in a console so the 
dump on exit
feature works.   Version 3.1.0 also fixes a timeout problem with very 
large dumps
so it may be worth testing with the prerelease version.  You can build 
from CVS
or I could get you a snapshot build if you need.
Note however that it the JVM is truly hung then thread dumps will not work

I always like to learn as much as possible about these problems so the 
Wrapper
can be improved, were possible, to make their root causes as obvious as 
possible.

Cheers,
Leif

[Wrapper-user] JVM hang causes

[Paul C. <cas...@au...>]

Hi all,

The JVM for the main process of our application (-Xmx1600M) was restarted
by the Java Service Wrapper today after pinging with no response from the
JVM for 10 mintues (as configured).

I can't for the life of me work out why it was hung though - there were no
exceptions in either the JSW log file nor the application's log file.

Moreover, when the JSW tried to get a thread dump on exit, it failed.
Here's a snippet from the log file:
ERROR  | wrapper  | 2004/02/17 12:02:55 | JVM appears hung: Timed out
waiting for signal from JVM.
STATUS | wrapper  | 2004/02/17 12:02:55 | Dumping JVM state.
DEBUG  | wrapper  | 2004/02/17 12:02:55 | Sending BREAK event to process
group 336.
ERROR  | wrapper  | 2004/02/17 12:02:55 | Unable to send BREAK event to JVM
process.  Err(6 : The handle is invalid. (0x6))
ERROR  | wrapper  | 2004/02/17 12:02:58 | Java Virtual Machine did not exit
on request, terminated

Before this was just 10 minutes of pinging without response from the JVM.
I know that noone can tell me what happened, but does anyone have some
ideas on where to start looking (ie make the haystack smaller so that the
needle is more obvious!).

Regards,

Paul Casanova

[Wrapper-user] timeout problem

[Alex V. <ale...@ap...>]

Hi,

I'm configuring the wrapper to never timeout =
(wrapper.startup.timeout=3D0),
but I still get a popup error message from windows after about 2 mins:

"Could not start the 'myService' service on local computer. Error 1053: =
the
service did not respond to the start or control request in a timely =
fashion"

I've also tried with 300 (5mns) and did not see any difference.

Any idea ?

Thanks, Alex.

Re: [Wrapper-user] Logging question

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

Alex,
    The Wrapper is designed to log everything that is sent to the 
console by the JVM
along with any and all logging information from the Wrapper process 
itself.  Normally
information sent to the console would simply be lost when running as a 
service as a
service does not have a console.

    If your application did not have a logging system, other than using 
the console, then
the Wrapper can be a handy fall back logging system.  But that is really 
not what it
is designed for.  Most applications should be using their own logging 
system within the
JVM.   That logging system can be used to control what is logged at any 
time as well
as where the individual log messages are sent.  Personally I have found 
that the most
useful thing to do is to have two log targets.
    One to the console which is designed for user consumption.   This 
all ends up in
the Wrapper.log file.
    The second goes to a file for developer / sys admin use.  It 
contains much the
same information as the first log file except that the messages also 
include any related
stack traces.   Things that are useful for debugging problems but would 
freak out
the idle user.

    While logging systems build within a Java application are very 
powerful.  There are
some things that they are not capable of doing.   One is to log low 
level console
output from the JVM.   This include thread dump output and core dump 
information
when the JVM process crashes.   The Wrapper is capable of capturing and 
logging
both.   But it this is because it is done outside of Java in the native 
Wrapper process.

    As for intercepting the System.err and System.out messages.   That 
is entirely
possible.    But you will only be redirecting the information within the 
JVM that was
sent to either stream.   This does not include the low level JVM output 
mentioned
above, or any messages that originate from the Wrapper process itself.  
These
will still end up in the wrapper.log file.    This is actually what you 
want.   Remember
that the Wrapper process is running before the JVM and thus your logging 
code is
started.  It is also running after it is shutdown.   The Wrapper will 
also still be running
if your JVM crashes, hangs, etc.   In other words, the Wrapper's logging 
mechanism
works in several circumstances where any Java based logging system will not
function.

    In version 3.0.5 of the Wrapper, intercepting System.out will also 
redirect all
output generated by the java component of the Wrapper.   This has been 
changed
for a number of reasons in 3.1.0.   Starting in the next release, such 
output is
always sent to the original System.out, ie. the console, even if 
System.out is
redirected for the rest of the application.  This should not affect user 
applications
in any way.  It does improve the reliability of the Wrapper in cases 
where the user
logging system is buggy, and helps with debugging the Wrapper by keeping 
all of
its output together in the wrapper.log file.

    I'm glad you are finding the Wrapper useful.

Let me know if you have any more questions.

Cheers,
Leif

Alex V. wrote:

>Hi All,
>
>My application is using its own logging component, built as a jdk1.4 style
>log handler (@see jdk1.4 logging APIs). Thus, when I run as an NT service
>using the (really cool I must say) wrapper, I end-up with two different log
>systems.
>
>I was wondering if there was a way to intercept/redirect all messages logged
>by the wrapper, including the System.out and System.err. If not, would
>support for jdk1.4 logging APIs be considered a legitimate enhancement
>request? 
>
>Also, if I redirect the System.err and System.out in my listener, am I going
>to intercept all messages logged by the wrapper?
>
>Rgrds, Alex.
>
>PS: Thanks for the 'set.PATH' hint; works jut fine for me.
>  
>

[Wrapper-user] Logging question

[Alex V. <ale...@ap...>]

Hi All,

My application is using its own logging component, built as a jdk1.4 =
style
log handler (@see jdk1.4 logging APIs). Thus, when I run as an NT =
service
using the (really cool I must say) wrapper, I end-up with two different =
log
systems.

I was wondering if there was a way to intercept/redirect all messages =
logged
by the wrapper, including the System.out and System.err. If not, would
support for jdk1.4 logging APIs be considered a legitimate enhancement
request?=20

Also, if I redirect the System.err and System.out in my listener, am I =
going
to intercept all messages logged by the wrapper?

Rgrds, Alex.

PS: Thanks for the 'set.PATH' hint; works jut fine for me.


-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: Saturday, February 14, 2004 10:39 AM
To: wra...@li...
Subject: Re: [Wrapper-user] DLL Issue


Alex,
    It is possible to modify the environment variables within the=20
Wrapper processs
along with its JVM by defining the following property in the=20
wrapper.conf file.

set.PATH=3D%PATH%;AdditionalPathInfo

    The set.x syntax allows you to set any environment variable.

Cheers,
Leif

Alex V. wrote:

> Hi,
> =20
> Here is a question: I need to ammend the value of the PATH environment
> variable when the service starts. Is it possible to configure the=20
> wrapper so that it executes with a given set of windows environment=20
> variables ? Is there a hook anywhere to tweek the windows environment=20
> variables when the service start ?
> =20
> Thanks, Alex.
> =20
> =20




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Trouble running as a service an app that replaces a standard java class

[Chris B. <chr...@ya...>]

Argh.  My apologizes.  I had set the env variable for my user but not for the system.  Everytime I ran from the command line it worked but as a service would always fail - no wonder.  Thanks for looking at this.  Everything seems to work fine now.
 
Chris

Leif Mortenson <le...@ta...> wrote:
Chris,
This one was easy. :-) Take a look at the Java command that the 
Wrapper is
generating to launch the JVM. When the Wrapper is running as a 
service, the
COUGAAR_INSTALL_PATH environment variable does not appear to be
defined. Because of this several of your system properties along with the
-Xbootclasspath are not being set correctly:

DEBUG | wrapper | 2004/02/16 09:12:54 | command: 
"C:\WINDOWS\system32\java.exe" 
-Dorg.cougaar.system.path=%COUGAAR_INSTALL_PATH%\sys 
-Dorg.cougaar.install.path=%COUGAAR_INSTALL_PATH% 
-Dorg.cougaar.core.servlet.enable=true 
-Dorg.cougaar.lib.web.scanRange=100 -Dorg.cougaar.lib.web.http.port=8800 
-Dorg.cougaar.lib.web.https.port=-1 
-Dorg.cougaar.lib.web.https.clientAuth=true 
-Dorg.cougaar.core.logging.config.filename=log.properties 
-Xbootclasspath/p:%COUGAAR_INSTALL_PATH%\lib\javaiopatch.jar -Xms50m 
-Xmx100m -Djava.library.path="..\lib" -classpath 
"..\lib\wrapper.jar;c:\bb\MetricsOperationsCenter\classes;C:\cougaar_10.4.2\lib\bootstrap.jar;C:\cougaar_10.4.2\lib\core.jar;C:\cougaar_10.4.2\lib\glm.jar;C:\cougaar_10.4.2\lib\planning.jar;C:\cougaar_10.4.2\lib\toolkit.jar;C:\cougaar_10.4.2\lib\util.jar;C:\cougaar_10.4.2\lib\webserver.jar;C:\cougaar_10.4.2\lib\webtomcat.jar;C:\cougaar_10.4.2\lib\community.jar;C:\cougaar_10.4.2\lib\javaiopatch.jar;C:\cougaar_10.4.2\sys\log4j.jar;C:\cougaar_10.4.2\sys\servlet.jar;C:\cougaar_10.4.2\sys\tomcat_40.jar" 
-Dwrapper.key="497dMLKMPftbRjqo" -Dwrapper.port=32000 
-Dwrapper.debug="TRUE" -Dwrapper.service="TRUE" 
-Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 
mil.darpa.bb.metrics.ServiceNode -c -n LsiNode

How is this environment variable being set when running as a console 
app?
Is it being set in your batch file? There are a couple ways to get this 
working
when running as a service.

The first is to set the environment variable in the System control 
panel. Make sure
it is set as a system wide variable or in the environment of the user 
running the
Wrapper, usually SYSTEM.

The second option is to tell the Wrapper to set the variable when it 
runs. This
can be done by defining a property: set.COUGAAR_INSTALL_PATH=C:/xxx
You can set the property in the wrapper.conf file. But most likely this 
is available
the batch file you are using to run the wrapper, so will will want to 
pass it as a
parameter to the Wrapper when it is used to install itself as a 
service. The Wrapper
will store any and all parameters in the registry so they can be reused 
later when
the service is actually run.

Your batch file would contain a line like the following:
Wrapper.exe -i ../conf/wrapper.conf set.COUGAAR_INSTALL_PATH=C:/xxx

Cheers,
Leif

Chris Brundick wrote:

> I've attached the wrapper.log generated with debug=true. Let me know 
> if you discover anything.
> 
> Thanks,
> Chris
>
> */Leif Mortenson /* wrote:
>
> Chris,
>
> Chris Brundick wrote:
>
> > Thanks for the reply Leif. I did as you suggested and attempted to
> > run after removing the -Dwrapper.key and it ran just fine. It's
> only
> > within the wrapper that I appear to have problems.
> >
> > I'm using the -Xbootclasspath:/p option on the java command line to
> > insert my class in front of the standard rt.jar, is it possible
> that
> > the wrapper has an issue with this?
>
> Playing with the core java classes completely destroys the
> portability
> of the program
> so it is not something that I have ever played with. I am sure you
> have
> a reason for
> doing so though. There are some security related issues that I would
> expect could arise
> because the main method is called from the wrapper's helper class
> which,
> unless you
> make it so, is not privileged code. However, as you say that running
> the same
> command generated by Wrapper works, I doubt this is the problem.
>
> I don't have any ideas on what might be causing this at the moment.
> Could you
> enable the wrapper.debug=true property in your conf file and then
> post
> the resulting
> debug output from a single launch of the JVM? I may have some ideas
> once I have
> seen the error in context.
>
> Cheers,
> Leif
>
> >
> > */Leif Mortenson /* wrote:
> >
> > Chris,
> > In general, that is not something you are supposed to do. But I
> > assume you
> > know that. :-)
> >
> > Normally, the rt.jar jar file is not located on the class path. I
> > believe it is looked at
> > before anything else on your classpath (??) I actually would not
> > expect
> > what you are
> > doing to work even when running Java manually, so I am not sure
> > why you
> > are only
> > having problems running with the Wrapper.
> >
> > Set the wrapper.debug=true property in your wrapper.conf file. This
> > will cause
> > the Wrapper to display the full Java command used to launch the
> > JVM in
> > the log.
> > Copy that full command into a fresh batch file. You will need to
> > remove the
> > -Dwrapper.key property from the command, but other than that you
> > should not
> > make any changes.
> > Now try running that script. It should behave exactly as it does
> > when running
> > under the Wrapper, only the Wrapper is now out of the equation. You
> > can then
> > fiddle with that batch file until you have things working. When you
> > know what the
> > problem was it should be easy to make the changes to the
> wrapper.conf
> > file to get
> > things working.
> >
> > Let me know if you have any questions while doing the above.
> >
> > Cheers,
> > Leif
> >
> > Chris Brundick wrote:
> >
> > > I'm very close to being able to run my application as a service in
> > > WinXP but I'm having an issue. I am replacing one of the standard
> > > java classes in java.io with my own version. I place my jar
> > > containing this class in the wrapper.java.classpath list in my
> > > wrapper.conf but it doesn't appear to recognize it. It seems to
> > work
> > > just fine in the console. Any thoughts?
>



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

---------------------------------
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online

Re: [Wrapper-user] Trouble running as a service an app that replaces a standard java class

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

Chris,
    This one was easy. :-)   Take a look at the Java command that the 
Wrapper is
generating to launch the JVM.   When the Wrapper is running as a 
service, the
COUGAAR_INSTALL_PATH environment variable does not appear to be
defined.  Because of this several of your system properties along with the
-Xbootclasspath are not being set correctly:

DEBUG  | wrapper  | 2004/02/16 09:12:54 | command: 
"C:\WINDOWS\system32\java.exe" 
-Dorg.cougaar.system.path=%COUGAAR_INSTALL_PATH%\sys 
-Dorg.cougaar.install.path=%COUGAAR_INSTALL_PATH% 
-Dorg.cougaar.core.servlet.enable=true 
-Dorg.cougaar.lib.web.scanRange=100 -Dorg.cougaar.lib.web.http.port=8800 
-Dorg.cougaar.lib.web.https.port=-1 
-Dorg.cougaar.lib.web.https.clientAuth=true 
-Dorg.cougaar.core.logging.config.filename=log.properties 
-Xbootclasspath/p:%COUGAAR_INSTALL_PATH%\lib\javaiopatch.jar -Xms50m 
-Xmx100m -Djava.library.path="..\lib" -classpath 
"..\lib\wrapper.jar;c:\bb\MetricsOperationsCenter\classes;C:\cougaar_10.4.2\lib\bootstrap.jar;C:\cougaar_10.4.2\lib\core.jar;C:\cougaar_10.4.2\lib\glm.jar;C:\cougaar_10.4.2\lib\planning.jar;C:\cougaar_10.4.2\lib\toolkit.jar;C:\cougaar_10.4.2\lib\util.jar;C:\cougaar_10.4.2\lib\webserver.jar;C:\cougaar_10.4.2\lib\webtomcat.jar;C:\cougaar_10.4.2\lib\community.jar;C:\cougaar_10.4.2\lib\javaiopatch.jar;C:\cougaar_10.4.2\sys\log4j.jar;C:\cougaar_10.4.2\sys\servlet.jar;C:\cougaar_10.4.2\sys\tomcat_40.jar" 
-Dwrapper.key="497dMLKMPftbRjqo" -Dwrapper.port=32000 
-Dwrapper.debug="TRUE" -Dwrapper.service="TRUE" 
-Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 
mil.darpa.bb.metrics.ServiceNode -c -n LsiNode

    How is this environment variable being set when running as a console 
app?
Is it being set in your batch file?  There are a couple ways to get this 
working
when running as a service.

    The first is to set the environment variable in the System control 
panel.  Make sure
it is set as a system wide variable or in the environment of the user 
running the
Wrapper, usually SYSTEM.

    The second option is to tell the Wrapper to set the variable when it 
runs.   This
can be done by defining a property: set.COUGAAR_INSTALL_PATH=C:/xxx
You can set the property in the wrapper.conf file.  But most likely this 
is available
the batch file you are using to run the wrapper, so will will want to 
pass it as a
parameter to the Wrapper when it is used to install itself as a 
service.  The Wrapper
will store any and all parameters in the registry so they can be reused 
later when
the service is actually run.

    Your batch file would contain a line like the following:
Wrapper.exe -i ../conf/wrapper.conf set.COUGAAR_INSTALL_PATH=C:/xxx

Cheers,
Leif

Chris Brundick wrote:

> I've attached the wrapper.log generated with debug=true.  Let me know 
> if you discover anything.
>  
> Thanks,
> Chris
>
> */Leif Mortenson <le...@ta...>/* wrote:
>
>     Chris,
>
>     Chris Brundick wrote:
>
>     > Thanks for the reply Leif. I did as you suggested and attempted to
>     > run after removing the -Dwrapper.key and it ran just fine. It's
>     only
>     > within the wrapper that I appear to have problems.
>     >
>     > I'm using the -Xbootclasspath:/p option on the java command line to
>     > insert my class in front of the standard rt.jar, is it possible
>     that
>     > the wrapper has an issue with this?
>
>     Playing with the core java classes completely destroys the
>     portability
>     of the program
>     so it is not something that I have ever played with. I am sure you
>     have
>     a reason for
>     doing so though. There are some security related issues that I would
>     expect could arise
>     because the main method is called from the wrapper's helper class
>     which,
>     unless you
>     make it so, is not privileged code. However, as you say that running
>     the same
>     command generated by Wrapper works, I doubt this is the problem.
>
>     I don't have any ideas on what might be causing this at the moment.
>     Could you
>     enable the wrapper.debug=true property in your conf file and then
>     post
>     the resulting
>     debug output from a single launch of the JVM? I may have some ideas
>     once I have
>     seen the error in context.
>
>     Cheers,
>     Leif
>
>     >
>     > */Leif Mortenson /* wrote:
>     >
>     > Chris,
>     > In general, that is not something you are supposed to do. But I
>     > assume you
>     > know that. :-)
>     >
>     > Normally, the rt.jar jar file is not located on the class path. I
>     > believe it is looked at
>     > before anything else on your classpath (??) I actually would not
>     > expect
>     > what you are
>     > doing to work even when running Java manually, so I am not sure
>     > why you
>     > are only
>     > having problems running with the Wrapper.
>     >
>     > Set the wrapper.debug=true property in your wrapper.conf file. This
>     > will cause
>     > the Wrapper to display the full Java command used to launch the
>     > JVM in
>     > the log.
>     > Copy that full command into a fresh batch file. You will need to
>     > remove the
>     > -Dwrapper.key property from the command, but other than that you
>     > should not
>     > make any changes.
>     > Now try running that script. It should behave exactly as it does
>     > when running
>     > under the Wrapper, only the Wrapper is now out of the equation. You
>     > can then
>     > fiddle with that batch file until you have things working. When you
>     > know what the
>     > problem was it should be easy to make the changes to the
>     wrapper.conf
>     > file to get
>     > things working.
>     >
>     > Let me know if you have any questions while doing the above.
>     >
>     > Cheers,
>     > Leif
>     >
>     > Chris Brundick wrote:
>     >
>     > > I'm very close to being able to run my application as a service in
>     > > WinXP but I'm having an issue. I am replacing one of the standard
>     > > java classes in java.io with my own version. I place my jar
>     > > containing this class in the wrapper.java.classpath list in my
>     > > wrapper.conf but it doesn't appear to recognize it. It seems to
>     > work
>     > > just fine in the console. Any thoughts?
>

Re: [Wrapper-user] Using WrapperStartStopApp with JBoss

[Rob M. <rob...@ya...>]

Thanks, Leif. Very cool. That information would be a nice addition to 
the site. I think it would help explain when you'd want to use one kind 
of wrapper class vs. another.

Gracias!

Rob

Leif Mortenson wrote:

> Rob,
>
>    Starting with Java 1.3, a feature called shutdown hooks were added
> to Java.  A
>
> method was added to the java.lang.Runtime class which allows you to
> register a
>
> Thread which will be started when the JVM starts to shutdown.   This 
> can be
>
> triggered by either hitting CTRL-C or by calling System.exit someplace
> in the
>
> code.
>
>    In the case of the Wrapper, a request by the Wrapper to shutdown the
>
> JVM results in System.exit being called from within the JVM.  This
> results in all
>
> registered shutdown hooks being executed before the JVM actually shuts 
> down.
>
> JBoss registers such a shutdown hook to handle the case where the user
> presses
>
> CTRL-C.  This makes it very easy to integrate with the Wrapper.
>
>    Tomcat on the other hand does not register any shutdown hooks and
> will this
>
> shutdown hard if you hit CTRL-C in the console.  In order to shut it
> down cleanly
>
> another class must be executed.  That is why its integration makes use
> of the
>
> WrapperStartStopApp helper class.
>
>
>
>    As a note, if you want your application to exit the JVM without
> executing any
>
> shutdown hooks you can do so by calling Runtime.getRuntime.halt()
>
>
>
>    Cheers,
>
>    Leif
>
>
>
> Rob Moore wrote:
>
>
>
>> Hi, Leif,
>
>
>>
>
>> Thanks for your response. The WrapperSimpleApp is working fine, but I 
>
>
>> just had the understanding that I needed to notify JBoss to shut 
>
>
>> itself down properly. From what you are saying, this is the case by 
>
>
>> default. I'm just curious how this is communicated to JBoss -- is it 
>
>
>> equivalent to hitting control-c in the console window?
>
>
>>
>
>> Rob
>
>
>>
>
>> Leif Mortenson wrote:
>
>
>>
>
>>> Rob,
>>
>
>>>
>
>>>    I have never tried that integration method with JBoss.  Is there a
>>
>
>>> reason why the
>>
>
>>>
>
>>> WrapperSimpleApp method is not working for you?  JBoss shuts down 
>>
>
>>> normally
>>
>
>>>
>
>>> using its own shutdown hook so you shouldn't have to be calling a stop
>>
>
>>> method.
>>
>
>>>
>
>>>
>
>>>
>
>>>    When using the WrapperStartStopApp, both the start and stop classes
>>
>
>>> are loaded
>>
>
>>>
>
>>> using the same class path.  This will only work for applications which
>>
>
>>> allow that.
>>
>
>>>
>
>>>
>
>>>
>
>>>    Also what are the errors you are seeing so I can help you without
>>
>
>>> trying to
>>
>
>>>
>
>>> reproduce your configuration in the dark.
>>
>
>>>
>
>>>
>
>>>
>
>>> Cheers,
>>
>
>>>
>
>>> Leif
>>
>
>>>
>
>>>
>
>>>
>
>>> Rob Moore wrote:
>>
>
>>>
>
>>>
>
>>>
>
>>>> Has anybody been able to get WrapperStartStopApp to work successfully
>>>
>
>>>
>
>>>
>
>>>
>
>>>> with JBoss?
>>>
>
>>>
>
>>>
>
>>>
>
>>>>
>
>>>
>
>>>> I would like to use the WrapperStartStopApp with JBoss, but I get
>>>
>
>>>
>
>>>
>
>>>
>
>>>> errors when I attempt to do so (I don't see the errors using
>>>
>
>>>
>
>>>
>
>>>
>
>>>> WrapperSimpleApp) that appear to be related to the classpath. It looks
>>>
>
>>>
>
>>>
>
>>>
>
>>>> like the problem results from the fact that I have to include all of
>>>
>
>>>
>
>>>
>
>>>
>
>>>> the jars needed for startup and shutdown. So I was curious if there is
>>>
>
>>>
>
>>>
>
>>>
>
>>>> a way to specify some jars in the classpath to be used for start and
>>>
>
>>>
>
>>>
>
>>>
>
>>>> others to be used for stop. 
>>>
>
>>>
>
>
>
>
>
>
>
> -------------------------------------------------------
>
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>
> Build and deploy apps & Web services for Linux with
>
> a free DVD software kit from IBM. Click Now!
>
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>
> _______________________________________________
>
> Wrapper-user mailing list
>
> Wra...@li...
>
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Trouble running as a service an app that replaces a standard java class

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

Chris,

Chris Brundick wrote:

> Thanks for the reply Leif.  I did as you suggested and attempted to 
> run after removing the -Dwrapper.key and it ran just fine.  It's only 
> within the wrapper that I appear to have problems.
>  
> I'm using the -Xbootclasspath:/p option on the java command line to 
> insert my class in front of the standard rt.jar, is it possible that 
> the wrapper has an issue with this?

Playing with the core java classes completely destroys the portability 
of the program
so it is not something that I have ever played with.  I am sure you have 
a reason for
doing so though.   There are some security related issues that I would 
expect could arise
because the main method is called from the wrapper's helper class which, 
unless you
make it so, is not privileged code.  However, as you say that running 
the same
command generated by Wrapper works, I doubt this is the problem.

I don't have any ideas on what might be causing this at the moment.  
Could you
enable the wrapper.debug=true property in your conf file and then post 
the resulting
debug output from a single launch of the JVM?   I may have some ideas 
once I have
seen the error in context.

Cheers,
Leif

>
> */Leif Mortenson <le...@ta...>/* wrote:
>
>     Chris,
>     In general, that is not something you are supposed to do. But I
>     assume you
>     know that. :-)
>
>     Normally, the rt.jar jar file is not located on the class path. I
>     believe it is looked at
>     before anything else on your classpath (??) I actually would not
>     expect
>     what you are
>     doing to work even when running Java manually, so I am not sure
>     why you
>     are only
>     having problems running with the Wrapper.
>
>     Set the wrapper.debug=true property in your wrapper.conf file. This
>     will cause
>     the Wrapper to display the full Java command used to launch the
>     JVM in
>     the log.
>     Copy that full command into a fresh batch file. You will need to
>     remove the
>     -Dwrapper.key property from the command, but other than that you
>     should not
>     make any changes.
>     Now try running that script. It should behave exactly as it does
>     when running
>     under the Wrapper, only the Wrapper is now out of the equation. You
>     can then
>     fiddle with that batch file until you have things working. When you
>     know what the
>     problem was it should be easy to make the changes to the wrapper.conf
>     file to get
>     things working.
>
>     Let me know if you have any questions while doing the above.
>
>     Cheers,
>     Leif
>
>     Chris Brundick wrote:
>
>     > I'm very close to being able to run my application as a service in
>     > WinXP but I'm having an issue. I am replacing one of the standard
>     > java classes in java.io with my own version. I place my jar
>     > containing this class in the wrapper.java.classpath list in my
>     > wrapper.conf but it doesn't appear to recognize it. It seems to
>     work
>     > just fine in the console. Any thoughts?
>

Re: [Wrapper-user] Using WrapperStartStopApp with JBoss

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

Rob,
    Starting with Java 1.3, a feature called shutdown hooks were added 
to Java.  A
method was added to the java.lang.Runtime class which allows you to 
register a
Thread which will be started when the JVM starts to shutdown.   This can be
triggered by either hitting CTRL-C or by calling System.exit someplace 
in the
code.
    In the case of the Wrapper, a request by the Wrapper to shutdown the
JVM results in System.exit being called from within the JVM.  This 
results in all
registered shutdown hooks being executed before the JVM actually shuts down.
JBoss registers such a shutdown hook to handle the case where the user 
presses
CTRL-C.  This makes it very easy to integrate with the Wrapper.
    Tomcat on the other hand does not register any shutdown hooks and 
will this
shutdown hard if you hit CTRL-C in the console.  In order to shut it 
down cleanly
another class must be executed.  That is why its integration makes use 
of the
WrapperStartStopApp helper class.

    As a note, if you want your application to exit the JVM without 
executing any
shutdown hooks you can do so by calling Runtime.getRuntime.halt()

    Cheers,
    Leif

Rob Moore wrote:

> Hi, Leif,
>
> Thanks for your response. The WrapperSimpleApp is working fine, but I 
> just had the understanding that I needed to notify JBoss to shut 
> itself down properly. From what you are saying, this is the case by 
> default. I'm just curious how this is communicated to JBoss -- is it 
> equivalent to hitting control-c in the console window?
>
> Rob
>
> Leif Mortenson wrote:
>
>> Rob,
>>
>>    I have never tried that integration method with JBoss.  Is there a
>> reason why the
>>
>> WrapperSimpleApp method is not working for you?  JBoss shuts down 
>> normally
>>
>> using its own shutdown hook so you shouldn't have to be calling a stop
>> method.
>>
>>
>>
>>    When using the WrapperStartStopApp, both the start and stop classes
>> are loaded
>>
>> using the same class path.  This will only work for applications which
>> allow that.
>>
>>
>>
>>    Also what are the errors you are seeing so I can help you without
>> trying to
>>
>> reproduce your configuration in the dark.
>>
>>
>>
>> Cheers,
>>
>> Leif
>>
>>
>>
>> Rob Moore wrote:
>>
>>
>>
>>> Has anybody been able to get WrapperStartStopApp to work successfully
>>
>>
>>
>>> with JBoss?
>>
>>
>>
>>>
>>
>>> I would like to use the WrapperStartStopApp with JBoss, but I get
>>
>>
>>
>>> errors when I attempt to do so (I don't see the errors using
>>
>>
>>
>>> WrapperSimpleApp) that appear to be related to the classpath. It looks
>>
>>
>>
>>> like the problem results from the fact that I have to include all of
>>
>>
>>
>>> the jars needed for startup and shutdown. So I was curious if there is
>>
>>
>>
>>> a way to specify some jars in the classpath to be used for start and
>>
>>
>>
>>> others to be used for stop. 
>>

Re: [Wrapper-user] Using WrapperStartStopApp with JBoss

[Rob M. <rob...@ya...>]

Hi, Leif,

Thanks for your response. The WrapperSimpleApp is working fine, but I 
just had the understanding that I needed to notify JBoss to shut itself 
down properly. From what you are saying, this is the case by default. 
I'm just curious how this is communicated to JBoss -- is it equivalent 
to hitting control-c in the console window?

Rob

Leif Mortenson wrote:

> Rob,
>
>    I have never tried that integration method with JBoss.  Is there a
> reason why the
>
> WrapperSimpleApp method is not working for you?  JBoss shuts down 
> normally
>
> using its own shutdown hook so you shouldn't have to be calling a stop
> method.
>
>
>
>    When using the WrapperStartStopApp, both the start and stop classes
> are loaded
>
> using the same class path.  This will only work for applications which
> allow that.
>
>
>
>    Also what are the errors you are seeing so I can help you without
> trying to
>
> reproduce your configuration in the dark.
>
>
>
> Cheers,
>
> Leif
>
>
>
> Rob Moore wrote:
>
>
>
>> Has anybody been able to get WrapperStartStopApp to work successfully
>
>
>> with JBoss?
>
>
>>
>
>> I would like to use the WrapperStartStopApp with JBoss, but I get
>
>
>> errors when I attempt to do so (I don't see the errors using
>
>
>> WrapperSimpleApp) that appear to be related to the classpath. It looks
>
>
>> like the problem results from the fact that I have to include all of
>
>
>> the jars needed for startup and shutdown. So I was curious if there is
>
>
>> a way to specify some jars in the classpath to be used for start and
>
>
>> others to be used for stop. 
>
>
>>  
>
>
>>
>
>
>
>
>
>
>
> -------------------------------------------------------
>
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>
> Build and deploy apps & Web services for Linux with
>
> a free DVD software kit from IBM. Click Now!
>
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>
> _______________________________________________
>
> Wrapper-user mailing list
>
> Wra...@li...
>
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Using WrapperStartStopApp with JBoss

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

Rob,
    I have never tried that integration method with JBoss.  Is there a 
reason why the
WrapperSimpleApp method is not working for you?  JBoss shuts down normally
using its own shutdown hook so you shouldn't have to be calling a stop 
method.

    When using the WrapperStartStopApp, both the start and stop classes 
are loaded
using the same class path.  This will only work for applications which 
allow that.

    Also what are the errors you are seeing so I can help you without 
trying to
reproduce your configuration in the dark.

Cheers,
Leif

Rob Moore wrote:

>Has anybody been able to get WrapperStartStopApp to work successfully
>with JBoss?
>
>I would like to use the WrapperStartStopApp with JBoss, but I get
>errors when I attempt to do so (I don't see the errors using
>WrapperSimpleApp) that appear to be related to the classpath. It looks
>like the problem results from the fact that I have to include all of
>the jars needed for startup and shutdown. So I was curious if there is
>a way to specify some jars in the classpath to be used for start and
>others to be used for stop. 
>  
>

Re: [Wrapper-user] Wrapper documentation request and a couple of questions

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

Mark,

Reed, Mark (MREED) wrote:

>Someone recently posted a question to this list regarding the wrapper
>hanging and not shutting down the wrapped application.
>The response was to read integration documentation more closely and to offer
>suggestions as to how the docs could be enhanced to help the user solve his
>problem. . I have spent a good deal of time reading the docs while
>implementing a project using the wrapper.
>The wrapper is great stuff, but I have a jew unanswered question that I have
>been trying to solve on my own without posting questions that are obviously
>answered in the docs.
>
>I have one suggestion or request regarding how the docs could be improved to
>help new users or users in general. The integration Method 3 states "The
>third and final method, while providing the most flexibility and access to
>all of the Wrapper's features"
>It would help if a clear distinction of what features are covered by each
>method and finally a clear list of the features that one gets by using each
>method that you dont get from the others. Specifically what is the list of
>features you get using Method 3 that you dont get with Method 1 or Method 2.
>Otherwise you study all three, study the example source provided and it a
>bit difficult to distinguish what you get from 3 that you dont get from 1 or
>2.
>I am trying to decide which method is best for my solution which is a fairly
>complex server application with lots of redundancy and availability
>requirements, remote support requirements via a Web based administration
>interface etc......
>I have used Methods 1 and Method 3 in some proof of concept code and was not
>quite successful with Method 3 due to my lack of understanding I'm sure. A
>better understanding of what you get from 3 as oppossed to 1 and 2 would
>help hence my intro paragraph.
>  
>
Thanks for the feedback.  I will go back and try improve the docs in the 
areas you
mentioned.

>Question 1:
>When using Method 1 and providing my own shut down hook, should I expect to
>be able to instantiate an instance of the WrapperActionServer and have it
>control my app for example sending an R to restart seems to have no effect
>so perhaps this is only usable with Method 3.
>  
>
The WrapperActionServer is designed so that it can be used with any of the 3
integration methods.   For security reasons none of the functions are 
enabled by
default.   You will need to enable the restart feature manually as follows:

            int port = 9999;
            WrapperActionServer server = new WrapperActionServer( port );
            server.enableRestartAction( true );
            server.start();

Let me know if that is not the problem.

>Question 2:
>When using Method 1 should I expect to be able to configure
>wrapper.filter.trigger.1=(some fully qualified exception name)
>wrapper.filter.action.1=RESTART
>throw this exception from some point in the application, no handle and
>therefore cause the Wrapper (using METHOD 1) to restart the service?
>  
>
The Wrapper is capable of triggering a restart or shutown when it 
detects a string from
the stdout or stderr of the JVM.   This works for any of the 3 
integration methods.  In
order for it to detect an exception, a message has to be send to stdout 
or stderr
however.  I am not clear.  Is this working for you?

>Question 3:
>What ways can i trigger this mechanism or the wrapper to see my string
>filter it and react. For example could I just perform a
>System.out("MYCOMMAND") and assuming i had 
>wrapper.filter.trigger.1=MYCOMMAND
>wrapper.filter.action.1=RESTART
>configured this would activate restart?
>  
>
Yes, that should work for you.

I modified the filter docs a little to make this a clearer.

Cheers,
Leif

Re: [Wrapper-user] DLL Issue

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

Alex,
    It is possible to modify the environment variables within the 
Wrapper processs
along with its JVM by defining the following property in the 
wrapper.conf file.

set.PATH=%PATH%;AdditionalPathInfo

    The set.x syntax allows you to set any environment variable.

Cheers,
Leif

Alex V. wrote:

> Hi,
>  
> Here is a question: I need to ammend the value of the PATH environment 
> variable when the service starts. Is it possible to configure the 
> wrapper so that it executes with a given set of windows environment 
> variables ? Is there a hook anywhere to tweek the windows environment 
> variables when the service start ?
>  
> Thanks, Alex.
>  
>  

RE: [Wrapper-user] DLL Issue

[Sal I. <sal...@vo...>]

Messageyou can run the wrapper under a user account instead of the system
account.
then you will be able to customize all the variables.
additionally you will be able to access domain resources like printers and
mount points to which your user has access.
  -----Original Message-----
  From: wra...@li...
[mailto:wra...@li...]On Behalf Of Alex V.
  Sent: Friday, February 13, 2004 11:36 PM
  To: wra...@li...
  Subject: [Wrapper-user] DLL Issue


  Hi,

  Here is a question: I need to ammend the value of the PATH environment
variable when the service starts. Is it possible to configure the wrapper so
that it executes with a given set of windows environment variables ? Is
there a hook anywhere to tweek the windows environment variables when the
service start ?

  Thanks, Alex.

[Wrapper-user] DLL Issue

[Alex V. <ale...@ap...>]

Hi,
=20
Here is a question: I need to ammend the value of the PATH environment
variable when the service starts. Is it possible to configure the =
wrapper so
that it executes with a given set of windows environment variables ? Is
there a hook anywhere to tweek the windows environment variables when =
the
service start ?
=20
Thanks, Alex.
=20
=20

[Wrapper-user] Wrapper documentation request and a couple of questions

[Reed, M. (MREED) <MR...@ar...>]

Someone recently posted a question to this list regarding the wrapper
hanging and not shutting down the wrapped application.
The response was to read integration documentation more closely and to offer
suggestions as to how the docs could be enhanced to help the user solve his
problem. . I have spent a good deal of time reading the docs while
implementing a project using the wrapper.
The wrapper is great stuff, but I have a jew unanswered question that I have
been trying to solve on my own without posting questions that are obviously
answered in the docs.

I have one suggestion or request regarding how the docs could be improved to
help new users or users in general. The integration Method 3 states "The
third and final method, while providing the most flexibility and access to
all of the Wrapper's features"
It would help if a clear distinction of what features are covered by each
method and finally a clear list of the features that one gets by using each
method that you dont get from the others. Specifically what is the list of
features you get using Method 3 that you dont get with Method 1 or Method 2.
Otherwise you study all three, study the example source provided and it a
bit difficult to distinguish what you get from 3 that you dont get from 1 or
2.
I am trying to decide which method is best for my solution which is a fairly
complex server application with lots of redundancy and availability
requirements, remote support requirements via a Web based administration
interface etc......
I have used Methods 1 and Method 3 in some proof of concept code and was not
quite successful with Method 3 due to my lack of understanding I'm sure. A
better understanding of what you get from 3 as oppossed to 1 and 2 would
help hence my intro paragraph.

Question 1:
When using Method 1 and providing my own shut down hook, should I expect to
be able to instantiate an instance of the WrapperActionServer and have it
control my app for example sending an R to restart seems to have no effect
so perhaps this is only usable with Method 3.
 
Question 2:
When using Method 1 should I expect to be able to configure
wrapper.filter.trigger.1=(some fully qualified exception name)
wrapper.filter.action.1=RESTART
throw this exception from some point in the application, no handle and
therefore cause the Wrapper (using METHOD 1) to restart the service?

Question 3:
What ways can i trigger this mechanism or the wrapper to see my string
filter it and react. For example could I just perform a
System.out("MYCOMMAND") and assuming i had 
wrapper.filter.trigger.1=MYCOMMAND
wrapper.filter.action.1=RESTART
configured this would activate restart?

Regards MRR

[Wrapper-user] Using WrapperStartStopApp with JBoss

[Rob M. <rob...@ya...>]

Has anybody been able to get WrapperStartStopApp to work successfully
with JBoss?

I would like to use the WrapperStartStopApp with JBoss, but I get
errors when I attempt to do so (I don't see the errors using
WrapperSimpleApp) that appear to be related to the classpath. It looks
like the problem results from the fact that I have to include all of
the jars needed for startup and shutdown. So I was curious if there is
a way to specify some jars in the classpath to be used for start and
others to be used for stop. 

Thanks,

Rob

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

Re: [Wrapper-user] HSQL Database service shutdown

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

Mikko,
    This is precisely what integration method #2, using the 
WrapperStartStopApp
helper class was developed for.    Take a look at that section of the 
integration docs
and post back if you have any other questions.

    I use HSQLDB quite a bit, but do so in my own component rather than 
running
as a standard server.   How does HSQLDB normally get shutdown.  If it 
does so
using shutdown hooks then the Wrapper will take care of that for you.

    Cheers,
    Leif


Mikko Valjento wrote:

>Hello all,
>
>I'm new Java Service Wrapper user and I'm running the HSQL Database as a
>service on my machine with the wrapper.
>
>I was wondering how to execute a shutdown command for the database when the
>service is stopped.
>
>As you might know the HSQLDB can be shut down by calling SQL 'SHUTDOWN'
>command. Now if I write a simple java class which only executes that command
>through jdbc, then is it possible to set that java class to be called when
>the hdbc service is stopped?
>
>Thanks for any advice,
>
>Mikko
>  
>

[Wrapper-user] HSQL Database service shutdown

[Mikko V. <mik...@so...>]

Hello all,

I'm new Java Service Wrapper user and I'm running the HSQL Database as a
service on my machine with the wrapper.

I was wondering how to execute a shutdown command for the database when the
service is stopped.

As you might know the HSQLDB can be shut down by calling SQL 'SHUTDOWN'
command. Now if I write a simple java class which only executes that command
through jdbc, then is it possible to set that java class to be called when
the hdbc service is stopped?

Thanks for any advice,

Mikko

[Wrapper-user] HSQL Database service shutdown

[Mikko V. <mi...@so...>]

Hello all,

I'm new Java Service Wrapper user and I'm running the HSQL Database as a
service on my machine with the wrapper.

I was wondering how to execute a shutdown command for the database when the
service is stopped.

As you might know the HSQLDB can be shut down by calling SQL 'SHUTDOWN'
command. Now if I write a simple java class which only executes that command
through jdbc, then is it possible to set that java class to be called when
the hdbc service is stopped?

Thanks for any advice,

Mikko

Re: [Wrapper-user] Trouble running as a service an app that replaces a standard java class

[Chris B. <chr...@ya...>]

Thanks for the reply Leif.  I did as you suggested and attempted to run after removing the -Dwrapper.key and it ran just fine.  It's only within the wrapper that I appear to have problems.
 
I'm using the -Xbootclasspath:/p option on the java command line to insert my class in front of the standard rt.jar, is it possible that the wrapper has an issue with this?
 
Thank you,
Chris

Leif Mortenson <le...@ta...> wrote:
Chris,
In general, that is not something you are supposed to do. But I 
assume you
know that. :-)

Normally, the rt.jar jar file is not located on the class path. I 
believe it is looked at
before anything else on your classpath (??) I actually would not expect 
what you are
doing to work even when running Java manually, so I am not sure why you 
are only
having problems running with the Wrapper.

Set the wrapper.debug=true property in your wrapper.conf file. This 
will cause
the Wrapper to display the full Java command used to launch the JVM in 
the log.
Copy that full command into a fresh batch file. You will need to remove the
-Dwrapper.key property from the command, but other than that you should not
make any changes.
Now try running that script. It should behave exactly as it does 
when running
under the Wrapper, only the Wrapper is now out of the equation. You 
can then
fiddle with that batch file until you have things working. When you 
know what the
problem was it should be easy to make the changes to the wrapper.conf 
file to get
things working.

Let me know if you have any questions while doing the above.

Cheers,
Leif

Chris Brundick wrote:

> I'm very close to being able to run my application as a service in 
> WinXP but I'm having an issue. I am replacing one of the standard 
> java classes in java.io with my own version. I place my jar 
> containing this class in the wrapper.java.classpath list in my 
> wrapper.conf but it doesn't appear to recognize it. It seems to work 
> just fine in the console. Any thoughts?




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

---------------------------------
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online

Re: [Wrapper-user] Trouble running as a service an app that replaces a standard java class

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

Chris,
    In general, that is not something you are supposed to do.  But I 
assume you
know that. :-)

    Normally, the rt.jar jar file is not located on the class path.  I 
believe it is looked at
before anything else on your classpath (??)  I actually would not expect 
what you are
doing to work even when running Java manually, so I am not sure why you 
are only
having problems running with the Wrapper.

    Set the wrapper.debug=true property in your wrapper.conf file.  This 
will cause
the Wrapper to display the full Java command used to launch the JVM in 
the log.
Copy that full command into a fresh batch file.  You will need to remove the
-Dwrapper.key property from the command, but other than that you should not
make any changes.
    Now try running that script.   It should behave exactly as it does 
when running
under the Wrapper, only the Wrapper is now out of the equation.   You 
can then
fiddle with that batch file until you have things working.  When you 
know what the
problem was it should be easy to make the changes to the wrapper.conf 
file to get
things working.

    Let me know if you have any questions while doing the above.

    Cheers,
    Leif

Chris Brundick wrote:

>   I'm very close to being able to run my application as a service in 
> WinXP but I'm having an issue.  I am replacing one of the standard 
> java classes in java.io with my own version.  I place my jar 
> containing this class in the wrapper.java.classpath list in my 
> wrapper.conf but it doesn't appear to recognize it.  It seems to work 
> just fine in the console.  Any thoughts?

[Wrapper-user] Trouble running as a service an app that replaces a standard java class

[Chris B. <chr...@ya...>]

  I'm very close to being able to run my application as a service in WinXP but I'm having an issue.  I am replacing one of the standard java classes in java.io with my own version.  I place my jar containing this class in the wrapper.java.classpath list in my wrapper.conf but it doesn't appear to recognize it.  It seems to work just fine in the console.  Any thoughts?


---------------------------------
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online

Re: [Wrapper-user] Wrapper using 100 percent cpu

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

Jeffrey,
Did you even look at the log file that you just sent me? You are getting
massive quantities of the following exception printed to the log file:

INFO | jvm 1 | 2004/02/12 09:21:04 | >Exceptionjava.io.IOException:
System.in can not be used when the JVM is being controlled by the Java
Service Manager.
INFO | jvm 1 | 2004/02/12 09:21:04 | >Exceptionjava.io.IOException:
System.in can not be used when the JVM is being controlled by the Java
Service Manager.
INFO | jvm 1 | 2004/02/12 09:21:04 | >Exceptionjava.io.IOException:
System.in can not be used when the JVM is being controlled by the Java
Service Manager.
INFO | jvm 1 | 2004/02/12 09:21:04 | >Exceptionjava.io.IOException:
System.in can not be used when the JVM is being controlled by the Java
Service Manager.

This log entry would have been visible even before you enabled debug
output.

As the exception states, the current version of the Wrapper does not
allow you to read input from System.in. This is due to the way stdin,
stdout, and stderr are mapped over to the Wrapper process.

Most likely you have a thread that is thrashing trying to read from
System.in That is what is eating up all of your CPU.

Cheers,
Leif

Jeffrey Hawley wrote:

> Leif,
>
> Sorry that I took so long to get back to you. I tried setting the
> priority to medium, then low, and last normal and the CPU usage was
> still 100%. I then added in the line wrapper.debug=true. I have
> attached the log file that includes installing, starting and then
> stopping the service while this line was in my .conf file. I look
> forward to hearing from you. Thank you.
>
> Jeffrey
>
>> From: Leif Mortenson <le...@ta...>
>> Reply-To: wra...@li...
>> To: wra...@li...
>> CC: jef...@ho...
>> Subject: Re: [Wrapper-user] Wrapper using 100 percent cpu
>> Date: Sat, 31 Jan 2004 12:26:22 +0900
>>
>> Jeffrey,
>> My answer is the same as to your previous yesterday. The SF servers have
>> been acting up the last few days. It may just be taking some time for
>> the replies
>> to come through. I'll CC you on this reply.
>>
>> The problem is most likely the following configuration.
>> wrapper.ntservice.process_priority=HIGH
>>
>> As explained in the docs, this would explain why your user processes
>> are not
>> able to stop the service. Try commenting out that line and rerunning.
>> Let me
>> know what happens. That shouldn't change the fact that your app is using
>> 100%
>> CPU, but it should let you control it.
>>
>> This mail says that the Wrapper uses 100% CPU when running as a service.
>> What happens when you run the Wrapper in console mode?
>>
>> Could you then take a look at your task manager and verify which
>> process is
>> eating all that CPU. The Wrapper or java process. They will both be
>> running
>> at the same priority. In my experience, I have never seen the Wrapper
>> process
>> even register. The Java process will only use CPU if the user code is
>> doing so.
>> The Wrapper classes are also very light weight.
>>
>> If that does not point you toward the solution, then please set the
>> following
>> property to enable debug output and then post the resulting log file. On
>> list
>> if small or to me directly if large.
>> wrapper.debug=true
>>
>> Cheers,
>> Leif
>>
>> Jeffrey Hawley wrote:
>>
>> > Hello All~
>> >
>> > I have recently configured PointBase Database to run as an NT service
>> > using wrapper. I have included my wrapper.conf file below and after
>> > installing PointBase I had to create the bin, conf and lib directories
>> > to store the appropriate files. I am running this on a Windows XP
>> > platform, but will evcentaully be placing it on a Windows Server 2003
>> > platform. Wrapper installs the service fine, but when I start the
>> > service it uses 97% of my CPU resources.
>> > I usually start the PointBase Server from the command prompt which
>> > allows admins to view current connections, list current system locks,
>> > and stop the server(how i currently kill it). Any help is much
>> > appreciated. Thanks in advance - Jeff.
>> >
>> > #********************************************************************
>> > # Wrapper Properties
>> > #********************************************************************
>> > wrapper.java.command=C:\j2sdk1.4.1_04\bin\java
>> > wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>> > wrapper.java.classpath.1=C:\pointbase\lib\wrapper.jar
>> > wrapper.java.classpath.2=C:\pointbase\lib\wrappertest.jar
>> > wrapper.java.classpath.3=C:\pointbase\lib\pbembedded47ev.jar
>> > wrapper.java.classpath.4=C:\pointbase\lib\pbtools47ev.jar
>> > wrapper.java.classpath.5=C:\pointbase\lib\POsqlserver47ev.jar
>> > wrapper.java.classpath.6=C:\pointbase\lib\POutil47ev.jar
>> > wrapper.java.classpath.7=C:\pointbase\lib\pbunisyncCore47ev.jar
>> > wrapper.java.classpath.8=C:\pointbase\lib\pbunisyncMIDPClient47ev.jar
>> > wrapper.java.classpath.9=C:\pointbase\lib\pbunisyncSQLServer47ev.jar
>> > wrapper.java.classpath.10=C:\pointbase\lib\pbunisyncTools47ev.jar
>> > wrapper.java.classpath.11=C:\pointbase\tools\unisync\lax.jar
>> > wrapper.java.library.path.1=C:\pointbase\lib
>> >
>> wrapper.java.additional.1=-Dpointbase.ini=C:\pointbase\tools\serveroption\pointbase.ini
>>
>> >
>> > wrapper.java.initmemory=3
>> > wrapper.java.maxmemory=64
>> > wrapper.app.parameter.1=com.pointbase.net.netServer
>> >
>> > #********************************************************************
>> > # Wrapper Logging Properties
>> > #********************************************************************
>> > wrapper.console.format=PM
>> > wrapper.console.loglevel=INFO
>> > wrapper.logfile=C:\pointbase\logs\wrapper.log
>> > wrapper.logfile.format=LPTM
>> > wrapper.logfile.loglevel=INFO
>> > wrapper.logfile.maxsize=0
>> > wrapper.logfile.maxfiles=0
>> > wrapper.syslog.loglevel=NONE
>> >
>> > #********************************************************************
>> > # Wrapper NT Service Properties
>> > #********************************************************************
>> > wrapper.ntservice.name=PointBaseDB
>> > wrapper.ntservice.displayname=PointBaseDB
>> > wrapper.ntservice.description=Runs the PointBase database as an NT
>> > Service
>> > wrapper.ntservice.dependency.1=
>> > wrapper.ntservice.starttype=AUTO_START
>> > wrapper.ntservice.interactive=false
>> > wrapper.ntservice.process_priority=HIGH
>> > wrapper.ntservice.interactive=false
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by EclipseCon 2004
>> Premiere Conference on Open Tools Development and Integration
>> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>> http://www.eclipsecon.org/osdn
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
> _________________________________________________________________
> Let the new MSN Premium Internet Software make the most of your
> high-speed experience.
> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1