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

Re: [Wrapper-user] Starting the Wrapper from the Command Line (Say for Profiling)

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

Robert,
    The Java side of the Wrapper looks for the wrapper.key property to 
decide whether or
not is being controlled by the Wrapper.   If it finds it then it will 
attempt to connect back to
the Wrapper and you will get the error you are seeing.

    To run the application without the Wrapper.  Copy the full command 
generated by the
Wrapper into a shell script.  Then remove the -Dwrapper.key="..." 
property from the
command.   Once you have done so, everything will work correctly.   Of 
course
features that require the Wrapper, like restarting will not work correctly.

Cheers,
Leif

Robert DiFalco wrote:

>I added the DEBUG flags to my configuration.
>
>Then I started the wrapper as usual.
>
>I was hoping I could take the command line and paste it into a
>dos-prompt to run the wrapper that way. Basically something like this:
>
>"..\jre\bin\java" 
>-Dtw.home="C:/apps/tnd" 
>-classpath "../lib/wrapper.jar;<other stuff> 
>-Dwrapper.key="..." -Dwrapper.port=32000 -Dwrapper.debug="TRUE" 
>-Dwrapper.use_system_time="TRUE" 
>-Dwrapper.version="3.1.1" 
>-Dwrapper.native_library="wrapper" 
>-Dwrapper.disable_shutdown_hook="TRUE" 
>-Dwrapper.cpu.timeout="10" 
>-Dwrapper.jvmid=1 
>com.tripwire.space.bootstrap.ServerLauncher
>
>However, when I do this, I get an exception. Here's the output:
>
>WrapperManager class initialized by thread: main  Using classloader:
>sun.misc.Launcher$AppClassLoader@e80a59
>Wrapper Manager: JVM #1
>Wrapper Manager: Using wrapper
>Loaded native library: wrapper.dll
>Calling native initialization method.
>Initializing WrapperManager native library.
>Java Executable: C:\apps\tnd\jre\bin\java.exe
>Windows version: 5.1.2600
>Java Version   : 1.4.2_02-b03 Java HotSpot(TM) Server VM
>Java VM Vendor : Sun Microsystems Inc.
>
>Wrapper (Version 3.1.1) http://wrapper.tanukisoftware.org
>
>WrapperManager.start(com.tripwire.space.bootstrap.ServerLauncher@152513a
>, args[]) called by thread: main
>Open socket to wrapper...
>Failed to connect to the Wrapper.
>java.net.ConnectException: Connection refused: connect
>Exiting JVM...
>WrapperManager.stopImmediate(1) called by thread: Wrapper-Connection
>Send a packet STOP : 1
>Send a packet STOPPED : 1
>
>Any ideas what I'm doing wrong?
>
>R.
>  
>

[Wrapper-user] Starting the Wrapper from the Command Line (Say for Profiling)

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

I added the DEBUG flags to my configuration.

Then I started the wrapper as usual.

I was hoping I could take the command line and paste it into a
dos-prompt to run the wrapper that way. Basically something like this:

"..\jre\bin\java"=20
-Dtw.home=3D"C:/apps/tnd"=20
-classpath "../lib/wrapper.jar;<other stuff>=20
-Dwrapper.key=3D"..." -Dwrapper.port=3D32000 -Dwrapper.debug=3D"TRUE"=20
-Dwrapper.use_system_time=3D"TRUE"=20
-Dwrapper.version=3D"3.1.1"=20
-Dwrapper.native_library=3D"wrapper"=20
-Dwrapper.disable_shutdown_hook=3D"TRUE"=20
-Dwrapper.cpu.timeout=3D"10"=20
-Dwrapper.jvmid=3D1=20
com.tripwire.space.bootstrap.ServerLauncher

However, when I do this, I get an exception. Here's the output:

WrapperManager class initialized by thread: main  Using classloader:
sun.misc.Launcher$AppClassLoader@e80a59
Wrapper Manager: JVM #1
Wrapper Manager: Using wrapper
Loaded native library: wrapper.dll
Calling native initialization method.
Initializing WrapperManager native library.
Java Executable: C:\apps\tnd\jre\bin\java.exe
Windows version: 5.1.2600
Java Version   : 1.4.2_02-b03 Java HotSpot(TM) Server VM
Java VM Vendor : Sun Microsystems Inc.

Wrapper (Version 3.1.1) http://wrapper.tanukisoftware.org

WrapperManager.start(com.tripwire.space.bootstrap.ServerLauncher@152513a
, args[]) called by thread: main
Open socket to wrapper...
Failed to connect to the Wrapper.
java.net.ConnectException: Connection refused: connect
Exiting JVM...
WrapperManager.stopImmediate(1) called by thread: Wrapper-Connection
Send a packet STOP : 1
Send a packet STOPPED : 1

Any ideas what I'm doing wrong?

R.

[Wrapper-user] Cant fid libjvm.so with setuid bit

[Mike C. <MCa...@cr...>]

Hi I am setting up a jboss server that is running on RedHat Linux (ES) 3.0.
I have the 1.4.2 jdk from sun installed, via rpm, in /usr/java/j2sdk...  I
have been using the Java Service Wrapper for the last couple of years and
have been very happy with it.  

 

My problem is this.  Initially I had everything set up to run my JBoss
instance via wrapper script and had it nicely integrated, no problems
everything works as expected.  However, I was running the service as root.
So I changed the ownership of all files in my jboss directory to jboss:jboss
(yes I made the user).  Then I set the user bit (setuid) on the wrapper
executeable file (chmod u+s wrapper).  When I do this I get the following
error when trying to run the service/daemon:

 

"Unable to load native library: libjvm.so: cannot open shared object file:
No such file or directory

 

If I chmod 777 the wrapper file it works just fine, even with the jboss
owner.  I did find a previous issue with libjvm.so here
http://sourceforge.net/mailarchive/message.php?msg_id=6815963
<http://sourceforge.net/mailarchive/message.php?msg_id=6815963>   but the
answer seemed to be that the jvm was corrupted which seems unlikely since it
all works when the uid bit of the wrapper file is not set.  The only thing I
can think of is that I explicitly list tools.jar in my classpath arguments
(this has always worked for me) but everything else should be pretty
standard.  Comparing with the log file that works there are no differences
until the after the "Launching  JVM..." output.

 

I did put the wrapper.debug parameter in the conf file here is the output:

 

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Spawning intermediate process...

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Spawning daemon process...

STATUS | wrapper  | 2004/08/06 16:05:18 | --> Wrapper Started as Daemon

DEBUG  | wrapperp | 2004/08/06 16:05:18 | server listening on port 32001.

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[0] :
/usr/java/j2sdk1.4.2_04/bin/java

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[1] :
-Dprogram.name=echo-run.sh

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[2] :
-Djboss.home=/usr/local/lib/jboss

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[3] : -Xdebug

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[4] :
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=18001

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[5] :
-Djava.library.path=../lib

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[6] : -classpath

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[7] :
../lib/wrapper.jar:../bin/run.jar:/usr/java/j2sdk1.4.2_04/lib/tools.jar

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[8] :
-Dwrapper.key=9KsZxLvqZXfQjzky

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[9] : -Dwrapper.port=32001

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[10] : -Dwrapper.debug=TRUE

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[11] :
-Dwrapper.use_system_time=TRUE

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[12] :
-Dwrapper.version=3.1.0

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[13] :
-Dwrapper.native_library=wrapper

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[14] :
-Dwrapper.service=TRUE

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[15] :
-Dwrapper.cpu.timeout=10

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[16] : -Dwrapper.jvmid=1

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[17] :
org.tanukisoftware.wrapper.WrapperSimpleApp

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[18] : org.jboss.Main

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[19] : -c

DEBUG  | wrapper  | 2004/08/06 16:05:18 | Command[20] : cc

STATUS | wrapper  | 2004/08/06 16:05:18 | Launching a JVM...

INFO   | jvm 1    | 2004/08/06 16:05:18 | Error occurred during
initialization of VM

INFO   | jvm 1    | 2004/08/06 16:05:18 | Unable to load native library:
libjvm.so: cannot open shared object file: No such file or directory

DEBUG  | wrapper  | 2004/08/06 16:05:18 | JVM process exited with a code of
1, setting the wrapper exit code to 1.

ERROR  | wrapper  | 2004/08/06 16:05:18 | JVM exited while loading the
application.

DEBUG  | wrapper  | 2004/08/06 16:05:18 | JVM was only running for 0 seconds
leading to a failed restart count of 1.

 

 

Thanks,

MC

 

Mike Cassisa

Software Engineer

Cricket Communications

10307 Pacific Center Court

San Diego, CA 92121

858-882-6096 Office

 

Computer Science is the discipline that believes all

problems can be solved with one more layer of indirection.

-Dennis DeBruler

 

Re: [Wrapper-user] Jboss Windows 2000 Server Service Problem

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

Paul,
The problem was being caused by the \" at the end of the library path.  
The Windows
Command interpreter uses the backslash to escape the quote.  So the 
error you saw
was being caused by the library path not being closed correctly.

I have fixed this for both the library path and classpath by adding a 
second backslash
before the quote when the path would normally end in a backslash.  The 
resulting
double backslash then escapes to a single backslash, and the quote correctly
terminates the path.

This will be in the 3.1.2 release.

Note that this is an issue with any of the parameter values to the JVM.  
The paths are
the only places where I control the quotes directly however.  I will 
make the strip
quotes properties work correctly on Unix platforms as there are also 
some related
issues there.

Cheers,
Leif

Paul Guilmette wrote:

>Thanks, I missed that. It now works fine.
>  
>

Re: [Wrapper-user] Wrapper restart failed

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

Paul,
    Looking at the logs you sent, I am trying to figure out exactly what 
caused the JVM to
shutdown?   As you said your server was restarted, but is that the 
reason why the JVM
shutdown?
    If the Wrapper had received a SHUTDOWN event from the system then 
there should
have been a STATUS level message with the following text:

STATUS | wrapper | Machine is shutting down.

    From the stack trace, it looks like the JVM received a system 
control event which in
turn caused the WrapperStartStopApp to shutdown the JVM and Wrapper.   
Without
the debug output, I can't tell you exactly what the signal was.  LOGOFF 
events are
ignored, so it must have been a SHUTDOWN event.  Because the JVM was running
as a service it could not have received a CTRL-C or CLOSE event.

    It looks like you had been experiencing OutOfMemory errors.   When 
the JVM
tried to shutdown, it correctly called your stop class's main method.  
But that class
then attempted to start a new thread.  This failed due to another 
OutOfMemory
error within your code.
    The exception was thrown all the way back up to the 
WrapperStartStopApp's
stop method.  When it caught this, it was wrapped in an 
InvocationTargetException.
This stack trace was correctly displayed.
    The code then went on to show the usage for the class.  This may be 
what was
confusing you.    Looking at the source again.  I don't think there are 
any cases
where the usage should be shown at this point.  I've remove it for the 
next version.

Cheers,
Leif

Paul Casanova wrote:

>
>
>Hi everyone,
>
>Had a strange one yesterday - the Wrapper normally restarts our app
>beautifully if it crashes - but yesterday it failed with the following from
>the wrapper log:
>
>INFO   | jvm 1    | 2004/08/05 14:01:52 | java.lang.OutOfMemoryError:
>unable to create new native thread
>INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
>java.lang.Thread.start(Native Method)
>INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
>sun.rmi.transport.tcp.TCPChannel.free(TCPChannel.java:286)
>INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
>sun.rmi.server.UnicastRef.invoke(UnicastRef.java:143)
>INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
>rcis.client.GI001RcisClient_Stub.isAlive(Unknown Source)
>INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
>rcis.admin.AA002LoggedInUser.isAlive(AA002UserAccessServer.java:1778)
>INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
>rcis.admin.AA002UserAccessServer.checkAlive(AA002UserAccessServer.java:460)
>INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
>rcis.admin.AA002UserAccessServer.run(AA002UserAccessServer.java:957)
>INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
>java.lang.Thread.run(Thread.java:479)
>INFO   | jvm 1    | 2004/08/05 14:03:14 | java.lang.OutOfMemoryError:
>unable to create new native thread
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>java.lang.Thread.start(Native Method)
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>sun.rmi.transport.tcp.TCPChannel.free(TCPChannel.java:286)
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>sun.rmi.server.UnicastRef.free(UnicastRef.java:429)
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>sun.rmi.server.UnicastRef.done(UnicastRef.java:449)
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>sun.rmi.transport.DGCImpl_Stub.dirty(Unknown Source)
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>sun.rmi.transport.DGCClient$EndpointEntry.makeDirtyCall(DGCClient.java:318)
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>sun.rmi.transport.DGCClient$EndpointEntry.access$1500(DGCClient.java:136)
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:529)
>INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
>java.lang.Thread.run(Thread.java:479)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |
>rcis.infra.GI002RcisRuntimeException: Failed to update accident
>(42004024365) while Recalculating Calculated Fields
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>rcis.coder.CA001AccidentDb.updateAccident(CA001AccidentDb.java:931)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>rcis.coder.CA001AccidentServer.doAccidentUpdate(CA001AccidentServer.java:293)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>rcis.coder.CA001AccidentServer.execute(CA001AccidentServer.java:105)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>java.lang.reflect.Method.invoke(Native Method)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>sun.rmi.transport.Transport$1.run(Transport.java:147)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>java.security.AccessController.doPrivileged(Native Method)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>sun.rmi.transport.Transport.serviceCall(Transport.java:143)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
>INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
>java.lang.Thread.run(Thread.java:479)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |
>rcis.infra.GI002RcisRuntimeException: Failed to update accident
>(42004023209) while deleting accident details
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>rcis.coder.CA001AccidentDb.updateAccident(CA001AccidentDb.java:931)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>rcis.coder.CA001AccidentServer.doAccidentUpdate(CA001AccidentServer.java:293)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>rcis.coder.CA001AccidentServer.execute(CA001AccidentServer.java:105)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>java.lang.reflect.Method.invoke(Native Method)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>sun.rmi.transport.Transport$1.run(Transport.java:147)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>java.security.AccessController.doPrivileged(Native Method)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>sun.rmi.transport.Transport.serviceCall(Transport.java:143)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
>INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
>java.lang.Thread.run(Thread.java:479)
>INFO   | jvm 1    | 2004/08/05 14:36:06 | Encountered an error running stop
>main: java.lang.reflect.InvocationTargetException
>INFO   | jvm 1    | 2004/08/05 14:36:06 |
>java.lang.reflect.InvocationTargetException: java.lang.OutOfMemoryError:
>unable to create new native thread
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>java.lang.Thread.start(Native Method)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>sun.rmi.transport.DGCClient$EndpointEntry.<init>(DGCClient.java:213)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>sun.rmi.transport.DGCClient$EndpointEntry.lookup(DGCClient.java:185)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>sun.rmi.transport.DGCClient.registerRefs(DGCClient.java:103)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>sun.rmi.transport.ConnectionInputStream.registerRefs(ConnectionInputStream.java:78)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>sun.rmi.transport.StreamRemoteCall.releaseInputStream(StreamRemoteCall.java:126)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>sun.rmi.transport.StreamRemoteCall.done(StreamRemoteCall.java:267)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>sun.rmi.server.UnicastRef.done(UnicastRef.java:452)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>java.rmi.Naming.lookup(Naming.java:79)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>rcis.infra.serverControl.GA001RCISMainServer.main(GA001RCISMainServer.java:63)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>java.lang.reflect.Method.invoke(Native Method)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>org.tanukisoftware.wrapper.WrapperStartStopApp.stop(WrapperStartStopApp.java:277)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>org.tanukisoftware.wrapper.WrapperManager.stopInner(WrapperManager.java:1903)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>org.tanukisoftware.wrapper.WrapperManager.stop(WrapperManager.java:1470)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>org.tanukisoftware.wrapper.WrapperStartStopApp.controlEvent(WrapperStartStopApp.java:357)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>org.tanukisoftware.wrapper.WrapperManager.controlEvent(WrapperManager.java:1982)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>org.tanukisoftware.wrapper.WrapperManager.access$1700(WrapperManager.java:232)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
>org.tanukisoftware.wrapper.WrapperManager$2.run(WrapperManager.java:655)
>INFO   | jvm 1    | 2004/08/05 14:36:06 |
>INFO   | jvm 1    | 2004/08/05 14:36:06 | WrapperStartStopApp Usage:
>INFO   | jvm 1    | 2004/08/05 14:36:06 |   java
>org.tanukisoftware.wrapper.WrapperStartStopApp {start_class}
>{start_arg_count} [start_arguments] {stop_class} {stop_wait}
>{stop_arg_count} [stop_arguments]
>INFO   | jvm 1    | 2004/08/05 14:36:06 |
>INFO   | jvm 1    | 2004/08/05 14:36:06 | Where:
>INFO   | jvm 1    | 2004/08/05 14:36:06 |   start_class:     The fully
>qualified class name to run to start the
>INFO   | jvm 1    | 2004/08/05 14:36:06 |                    application.
>INFO   | jvm 1    | 2004/08/05 14:36:06 |   start_arg_count: The number of
>arguments to be passed to the start class's
>INFO   | jvm 1    | 2004/08/05 14:36:06 |                    main method.
>INFO   | jvm 1    | 2004/08/05 14:36:06 |   stop_class:      The fully
>qualified class name to run to stop the
>INFO   | jvm 1    | 2004/08/05 14:36:06 |                    application.
>INFO   | jvm 1    | 2004/08/05 14:36:06 |   stop_wait:       When stopping,
>should the Wrapper wait for all threads to
>INFO   | jvm 1    | 2004/08/05 14:36:06 |                    complete
>before exiting (true/false).
>INFO   | jvm 1    | 2004/08/05 14:36:06 |   stop_arg_count:  The number of
>arguments to be passed to the stop class's
>INFO   | jvm 1    | 2004/08/05 14:36:06 |                    main method.
>INFO   | jvm 1    | 2004/08/05 14:36:06 |   app_parameters:  The parameters
>that would normally be passed to the
>INFO   | jvm 1    | 2004/08/05 14:36:06 |                    application.
>STATUS | wrapper  | 2004/08/05 14:36:07 | <-- Wrapper Stopped
>STATUS | wrapper  | 2004/08/05 14:39:26 | --> Wrapper Started as Service
>STATUS | wrapper  | 2004/08/05 14:39:27 | Launching a JVM...
>
>Where the Wrapper started again a few minutes later was due to the server
>being rebooted.  I upgraded to 3.1.1 last night - does anyone know what may
>have caused the Wrapper restarting to fail?
>
>Regards,
>
>Paul Casanova
>  
>

Re: [Wrapper-user] Jboss Windows 2000 Server Service Problem

[Paul G. <PGu...@ps...>]

Thanks, I missed that. It now works fine.

Paul W. Guilmette
Sr. Programmer Analyst
PSCU Financial Services
727-572-7723 ext 2247


>>> le...@ta... 08/06/2004 3:15:52 AM >>>
Paul,
Sorry for the slow reply. I copied the Full Java commands out of your
good and
bad wrapper.logs and did a comparison. It looks like like it is
working
for you when
running in a console, but failing when running as a service.

I as able to narrow the problem down to the library class path.
When running as a console it is:
-Djava.library.path="../lib;<clip>;C:\Program Files\Resource
Kit\;C:\PROGRA~1\Eicon\Eicon Shared\System;Z:.;Y:.;X:.;W:.;V:."

But when running as a service it is:
-Djava.library.path="../lib;<clip>;C:\Program Files\Resource Kit\"

The problem seems to be that final backslash. I am not sure exactly
why
but it is
affecting Java's ability to parse the command line. If I change it to
-Djava.library.path="../lib;<clip>;C:\Program Files\Resource Kit\;"
then
everything
works correctly.

I am going to need to do some investigating to figure out exactly why
this is
happening however. But this will be easy enough to work around within
the
Wrapper. If the path ends in a \ then I add an extra ; I want to
understand
exactly where this is causing problems. I would need a different fix
if
it is also
going to be a problem for other system property definitions for
example.

For now, can you try going in and modifying your PATH environment
variable so
it does not end in a \?

Cheers,
Leif

Paul Guilmette wrote:

>Here is a  debug good and bad wrapper log and my wrapper.conf
>
>the lines look the same
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes
on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source
Technology
Group. Come see the changes on the new OSTG site. www.ostg.com 
_______________________________________________
Wrapper-user mailing list
Wra...@li... 
https://lists.sourceforge.net/lists/listinfo/wrapper-user


-----------------------------------------------------------------------
This e-mail is intended for the addressee shown. 
It contains information that is confidential and 
protected from disclosure. Any review, dissemination 
or use of this transmission or its contents by persons 
or unauthorized employees of the intended organizations 
is strictly prohibited. 

The contents of this email do not necessarily represent 
the views or policies of PSCU Financial Services.

Re: [Wrapper-user] Jboss Windows 2000 Server Service Problem

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

Paul,
Sorry for the slow reply. I copied the Full Java commands out of your
good and
bad wrapper.logs and did a comparison. It looks like like it is working
for you when
running in a console, but failing when running as a service.

I as able to narrow the problem down to the library class path.
When running as a console it is:
-Djava.library.path="../lib;<clip>;C:\Program Files\Resource
Kit\;C:\PROGRA~1\Eicon\Eicon Shared\System;Z:.;Y:.;X:.;W:.;V:."

But when running as a service it is:
-Djava.library.path="../lib;<clip>;C:\Program Files\Resource Kit\"

The problem seems to be that final backslash. I am not sure exactly why
but it is
affecting Java's ability to parse the command line. If I change it to
-Djava.library.path="../lib;<clip>;C:\Program Files\Resource Kit\;" then
everything
works correctly.

I am going to need to do some investigating to figure out exactly why
this is
happening however. But this will be easy enough to work around within the
Wrapper. If the path ends in a \ then I add an extra ; I want to understand
exactly where this is causing problems. I would need a different fix if
it is also
going to be a problem for other system property definitions for example.

For now, can you try going in and modifying your PATH environment
variable so
it does not end in a \?

Cheers,
Leif

Paul Guilmette wrote:

>Here is a  debug good and bad wrapper log and my wrapper.conf
>
>the lines look the same
>  
>

[Wrapper-user] Wrapper restart failed

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

Hi everyone,

Had a strange one yesterday - the Wrapper normally restarts our app
beautifully if it crashes - but yesterday it failed with the following from
the wrapper log:

INFO   | jvm 1    | 2004/08/05 14:01:52 | java.lang.OutOfMemoryError:
unable to create new native thread
INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
java.lang.Thread.start(Native Method)
INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
sun.rmi.transport.tcp.TCPChannel.free(TCPChannel.java:286)
INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
sun.rmi.server.UnicastRef.invoke(UnicastRef.java:143)
INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
rcis.client.GI001RcisClient_Stub.isAlive(Unknown Source)
INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
rcis.admin.AA002LoggedInUser.isAlive(AA002UserAccessServer.java:1778)
INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
rcis.admin.AA002UserAccessServer.checkAlive(AA002UserAccessServer.java:460)
INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
rcis.admin.AA002UserAccessServer.run(AA002UserAccessServer.java:957)
INFO   | jvm 1    | 2004/08/05 14:01:52 |       at
java.lang.Thread.run(Thread.java:479)
INFO   | jvm 1    | 2004/08/05 14:03:14 | java.lang.OutOfMemoryError:
unable to create new native thread
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
java.lang.Thread.start(Native Method)
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
sun.rmi.transport.tcp.TCPChannel.free(TCPChannel.java:286)
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
sun.rmi.server.UnicastRef.free(UnicastRef.java:429)
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
sun.rmi.server.UnicastRef.done(UnicastRef.java:449)
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
sun.rmi.transport.DGCImpl_Stub.dirty(Unknown Source)
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
sun.rmi.transport.DGCClient$EndpointEntry.makeDirtyCall(DGCClient.java:318)
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
sun.rmi.transport.DGCClient$EndpointEntry.access$1500(DGCClient.java:136)
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:529)
INFO   | jvm 1    | 2004/08/05 14:03:14 |       at
java.lang.Thread.run(Thread.java:479)
INFO   | jvm 1    | 2004/08/05 14:03:24 |
rcis.infra.GI002RcisRuntimeException: Failed to update accident
(42004024365) while Recalculating Calculated Fields
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
rcis.coder.CA001AccidentDb.updateAccident(CA001AccidentDb.java:931)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
rcis.coder.CA001AccidentServer.doAccidentUpdate(CA001AccidentServer.java:293)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
rcis.coder.CA001AccidentServer.execute(CA001AccidentServer.java:105)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
java.lang.reflect.Method.invoke(Native Method)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
sun.rmi.transport.Transport$1.run(Transport.java:147)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
java.security.AccessController.doPrivileged(Native Method)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
sun.rmi.transport.Transport.serviceCall(Transport.java:143)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
INFO   | jvm 1    | 2004/08/05 14:03:24 |       at
java.lang.Thread.run(Thread.java:479)
INFO   | jvm 1    | 2004/08/05 14:10:22 |
rcis.infra.GI002RcisRuntimeException: Failed to update accident
(42004023209) while deleting accident details
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
rcis.coder.CA001AccidentDb.updateAccident(CA001AccidentDb.java:931)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
rcis.coder.CA001AccidentServer.doAccidentUpdate(CA001AccidentServer.java:293)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
rcis.coder.CA001AccidentServer.execute(CA001AccidentServer.java:105)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
java.lang.reflect.Method.invoke(Native Method)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
sun.rmi.transport.Transport$1.run(Transport.java:147)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
java.security.AccessController.doPrivileged(Native Method)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
sun.rmi.transport.Transport.serviceCall(Transport.java:143)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
INFO   | jvm 1    | 2004/08/05 14:10:22 |       at
java.lang.Thread.run(Thread.java:479)
INFO   | jvm 1    | 2004/08/05 14:36:06 | Encountered an error running stop
main: java.lang.reflect.InvocationTargetException
INFO   | jvm 1    | 2004/08/05 14:36:06 |
java.lang.reflect.InvocationTargetException: java.lang.OutOfMemoryError:
unable to create new native thread
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
java.lang.Thread.start(Native Method)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
sun.rmi.transport.DGCClient$EndpointEntry.<init>(DGCClient.java:213)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
sun.rmi.transport.DGCClient$EndpointEntry.lookup(DGCClient.java:185)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
sun.rmi.transport.DGCClient.registerRefs(DGCClient.java:103)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
sun.rmi.transport.ConnectionInputStream.registerRefs(ConnectionInputStream.java:78)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
sun.rmi.transport.StreamRemoteCall.releaseInputStream(StreamRemoteCall.java:126)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
sun.rmi.transport.StreamRemoteCall.done(StreamRemoteCall.java:267)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
sun.rmi.server.UnicastRef.done(UnicastRef.java:452)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
java.rmi.Naming.lookup(Naming.java:79)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
rcis.infra.serverControl.GA001RCISMainServer.main(GA001RCISMainServer.java:63)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
java.lang.reflect.Method.invoke(Native Method)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
org.tanukisoftware.wrapper.WrapperStartStopApp.stop(WrapperStartStopApp.java:277)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
org.tanukisoftware.wrapper.WrapperManager.stopInner(WrapperManager.java:1903)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
org.tanukisoftware.wrapper.WrapperManager.stop(WrapperManager.java:1470)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
org.tanukisoftware.wrapper.WrapperStartStopApp.controlEvent(WrapperStartStopApp.java:357)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
org.tanukisoftware.wrapper.WrapperManager.controlEvent(WrapperManager.java:1982)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
org.tanukisoftware.wrapper.WrapperManager.access$1700(WrapperManager.java:232)
INFO   | jvm 1    | 2004/08/05 14:36:06 |       at
org.tanukisoftware.wrapper.WrapperManager$2.run(WrapperManager.java:655)
INFO   | jvm 1    | 2004/08/05 14:36:06 |
INFO   | jvm 1    | 2004/08/05 14:36:06 | WrapperStartStopApp Usage:
INFO   | jvm 1    | 2004/08/05 14:36:06 |   java
org.tanukisoftware.wrapper.WrapperStartStopApp {start_class}
{start_arg_count} [start_arguments] {stop_class} {stop_wait}
{stop_arg_count} [stop_arguments]
INFO   | jvm 1    | 2004/08/05 14:36:06 |
INFO   | jvm 1    | 2004/08/05 14:36:06 | Where:
INFO   | jvm 1    | 2004/08/05 14:36:06 |   start_class:     The fully
qualified class name to run to start the
INFO   | jvm 1    | 2004/08/05 14:36:06 |                    application.
INFO   | jvm 1    | 2004/08/05 14:36:06 |   start_arg_count: The number of
arguments to be passed to the start class's
INFO   | jvm 1    | 2004/08/05 14:36:06 |                    main method.
INFO   | jvm 1    | 2004/08/05 14:36:06 |   stop_class:      The fully
qualified class name to run to stop the
INFO   | jvm 1    | 2004/08/05 14:36:06 |                    application.
INFO   | jvm 1    | 2004/08/05 14:36:06 |   stop_wait:       When stopping,
should the Wrapper wait for all threads to
INFO   | jvm 1    | 2004/08/05 14:36:06 |                    complete
before exiting (true/false).
INFO   | jvm 1    | 2004/08/05 14:36:06 |   stop_arg_count:  The number of
arguments to be passed to the stop class's
INFO   | jvm 1    | 2004/08/05 14:36:06 |                    main method.
INFO   | jvm 1    | 2004/08/05 14:36:06 |   app_parameters:  The parameters
that would normally be passed to the
INFO   | jvm 1    | 2004/08/05 14:36:06 |                    application.
STATUS | wrapper  | 2004/08/05 14:36:07 | <-- Wrapper Stopped
STATUS | wrapper  | 2004/08/05 14:39:26 | --> Wrapper Started as Service
STATUS | wrapper  | 2004/08/05 14:39:27 | Launching a JVM...

Where the Wrapper started again a few minutes later was due to the server
being rebooted.  I upgraded to 3.1.1 last night - does anyone know what may
have caused the Wrapper restarting to fail?

Regards,

Paul Casanova

[Wrapper-user] Windows 2000 Service problem

[Paul G. <PGu...@ps...>]

Here is a cut down version of the logs. I could not spot a problem. see
if you can.

Paul W. Guilmette
Sr. Programmer Analyst
PSCU Financial Services
727-572-7723 ext 2247




-----------------------------------------------------------------------
This e-mail is intended for the addressee shown. 
It contains information that is confidential and 
protected from disclosure. Any review, dissemination 
or use of this transmission or its contents by persons 
or unauthorized employees of the intended organizations 
is strictly prohibited. 

The contents of this email do not necessarily represent 
the views or policies of PSCU Financial Services.

[Wrapper-user] Jboss Windows 2000 Server Service Problem

[Paul G. <PGu...@ps...>]

Here is a  debug good and bad wrapper log and my wrapper.conf

the lines look the same


Paul W. Guilmette
Sr. Programmer Analyst
PSCU Financial Services
727-572-7723 ext 2247




-----------------------------------------------------------------------
This e-mail is intended for the addressee shown. 
It contains information that is confidential and 
protected from disclosure. Any review, dissemination 
or use of this transmission or its contents by persons 
or unauthorized employees of the intended organizations 
is strictly prohibited. 

The contents of this email do not necessarily represent 
the views or policies of PSCU Financial Services.

[Wrapper-user] Jboss Windows 2000 Server Service Problem

[Paul G. <PGu...@ps...>]

Here is the Jboss.bat that is good a debug good and bad wrapper log and
my wrapper.conf

Paul W. Guilmette
Sr. Programmer Analyst
PSCU Financial Services
727-572-7723 ext 2247




-----------------------------------------------------------------------
This e-mail is intended for the addressee shown. 
It contains information that is confidential and 
protected from disclosure. Any review, dissemination 
or use of this transmission or its contents by persons 
or unauthorized employees of the intended organizations 
is strictly prohibited. 

The contents of this email do not necessarily represent 
the views or policies of PSCU Financial Services.


nws attachment type blocked 
This message contained attachments that have been blocked
by Guinevere. 

If you were expecting this email, please contact the 
sender to make other arangements for receiving the file(s).

Re: [Wrapper-user] NT Event Log levels etc

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

Rob Pearson wrote:

>I just started playing with this product - very impressed. Great features.
>  
>
Thanks.  Glad you hear you are finding it useful.

>One question I have, when logging to the windows event log, is there any way
>to set the Category or Event of the message. Category seems to be "jvm1" or
>"wrapper", and Event is always 100. Can I change these?
>
>Also, can I change the event Type to be based on what gets output from my app
>(ie other that setting them all to the same level using wrapper.syslog.loglevel)
>  
>
It looks like you have a clear grasp on what is currently possible with 
the Wrapper.  The above
values are not at all configurable.   To be honest, I never use the 
Event Log personally so have
not expended much effort at improving that feature.   Nor am I a good 
source of ideas for what
would be useful to be able to do.

If you could list up what you would like to be possible and explain a 
bit how each feature
would be used, I will look at getting your ideas into a future version.

Cheers,
Leif

Re: [Wrapper-user] Jboss Windows 2000 Service Problem

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

Paul,
    Most likely this is a simple mistake in the wrapper.conf file.   Add 
the wrapper.debug=true
property to the wrapper.conf and try again.  Amongst other information, 
this will cause the
full command used to launch the JVM to be printed to the log.  Once you 
have seen that the
difference between it and the batch file should become obvious.

    I am curious what exact mistake would cause this, so do post back.   
Also if you are still
having problems, post back with your wrapper.conf and the wrapper.log 
(with debug output)
as attachments (not inline due to line wrapping).

Cheers,
Leif

Paul Guilmette wrote:

>When I run jboss.bat the wrapper works fine but when I run it as a
>service  it gives me like it doesn't know how to launch the JVM. What am
>I missing?
>
>STATUS | wrapper  | 2004/07/28 09:31:15 | --> Wrapper Started as
>Service
>STATUS | wrapper  | 2004/07/28 09:31:15 | Launching a JVM...
>INFO   | jvm 1    | 2004/07/28 09:31:15 | Usage: java [-options] class
>[args...]
>INFO   | jvm 1    | 2004/07/28 09:31:15 |            (to execute a
>class)
>INFO   | jvm 1    | 2004/07/28 09:31:15 |    or  java [-options] -jar
>jarfile [args...]
>INFO   | jvm 1    | 2004/07/28 09:31:15 |            (to execute a jar
>file)
>INFO   | jvm 1    | 2004/07/28 09:31:15 | 
>INFO   | jvm 1    | 2004/07/28 09:31:15 | where options include:
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -client	  to select the
>"client" VM
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -server	  to select the
>"server" VM
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -hotspot	  is a synonym
>for the "client" VM  [deprecated]
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   The default
>VM is client.
>INFO   | jvm 1    | 2004/07/28 09:31:15 | 
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -cp <class search path of
>directories and zip/jar files>
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -classpath <class search
>path of directories and zip/jar files>
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   A ;
>separated list of directories, JAR archives,
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   and ZIP
>archives to search for class files.
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -D<name>=<value>
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   set a
>system property
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -verbose[:class|gc|jni]
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   enable
>verbose output
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -version      print
>product version and exit
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -showversion  print
>product version and continue
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -? -help      print this
>help message
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -X            print help
>on non-standard options
>INFO   | jvm 1    | 2004/07/28 09:31:15 |    
>-ea[:<packagename>...|:<classname>]
>INFO   | jvm 1    | 2004/07/28 09:31:15 |    
>-enableassertions[:<packagename>...|:<classname>]
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   enable
>assertions
>INFO   | jvm 1    | 2004/07/28 09:31:15 |    
>-da[:<packagename>...|:<classname>]
>INFO   | jvm 1    | 2004/07/28 09:31:15 |    
>-disableassertions[:<packagename>...|:<classname>]
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   disable
>assertions
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -esa |
>-enablesystemassertions
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   enable
>system assertions
>INFO   | jvm 1    | 2004/07/28 09:31:15 |     -dsa |
>-disablesystemassertions
>INFO   | jvm 1    | 2004/07/28 09:31:15 |                   disable
>system assertions
>  
>

[Wrapper-user] Jboss Windows 2000 Service Problem

[Paul G. <PGu...@ps...>]

When I run jboss.bat the wrapper works fine but when I run it as a
service  it gives me like it doesn't know how to launch the JVM. What am
I missing?

STATUS | wrapper  | 2004/07/28 09:31:15 | --> Wrapper Started as
Service
STATUS | wrapper  | 2004/07/28 09:31:15 | Launching a JVM...
INFO   | jvm 1    | 2004/07/28 09:31:15 | Usage: java [-options] class
[args...]
INFO   | jvm 1    | 2004/07/28 09:31:15 |            (to execute a
class)
INFO   | jvm 1    | 2004/07/28 09:31:15 |    or  java [-options] -jar
jarfile [args...]
INFO   | jvm 1    | 2004/07/28 09:31:15 |            (to execute a jar
file)
INFO   | jvm 1    | 2004/07/28 09:31:15 | 
INFO   | jvm 1    | 2004/07/28 09:31:15 | where options include:
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -client	  to select the
"client" VM
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -server	  to select the
"server" VM
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -hotspot	  is a synonym
for the "client" VM  [deprecated]
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   The default
VM is client.
INFO   | jvm 1    | 2004/07/28 09:31:15 | 
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -cp <class search path of
directories and zip/jar files>
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -classpath <class search
path of directories and zip/jar files>
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   A ;
separated list of directories, JAR archives,
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   and ZIP
archives to search for class files.
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -D<name>=<value>
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   set a
system property
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -verbose[:class|gc|jni]
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   enable
verbose output
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -version      print
product version and exit
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -showversion  print
product version and continue
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -? -help      print this
help message
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -X            print help
on non-standard options
INFO   | jvm 1    | 2004/07/28 09:31:15 |    
-ea[:<packagename>...|:<classname>]
INFO   | jvm 1    | 2004/07/28 09:31:15 |    
-enableassertions[:<packagename>...|:<classname>]
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   enable
assertions
INFO   | jvm 1    | 2004/07/28 09:31:15 |    
-da[:<packagename>...|:<classname>]
INFO   | jvm 1    | 2004/07/28 09:31:15 |    
-disableassertions[:<packagename>...|:<classname>]
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   disable
assertions
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -esa |
-enablesystemassertions
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   enable
system assertions
INFO   | jvm 1    | 2004/07/28 09:31:15 |     -dsa |
-disablesystemassertions
INFO   | jvm 1    | 2004/07/28 09:31:15 |                   disable
system assertions


Paul W. Guilmette
Sr. Programmer Analyst
PSCU Financial Services
727-572-7723 ext 2247



-----------------------------------------------------------------------
This e-mail is intended for the addressee shown. 
It contains information that is confidential and 
protected from disclosure. Any review, dissemination 
or use of this transmission or its contents by persons 
or unauthorized employees of the intended organizations 
is strictly prohibited. 

The contents of this email do not necessarily represent 
the views or policies of PSCU Financial Services.

[Wrapper-user] NT Event Log levels etc

[Rob P. <rob...@id...>]

Hi,

I just started playing with this product - very impressed. Great features.

One question I have, when logging to the windows event log, is there any way
to set the Category or Event of the message. Category seems to be "jvm1" or
"wrapper", and Event is always 100. Can I change these?

Also, can I change the event Type to be based on what gets output from my app
(ie other that setting them all to the same level using wrapper.syslog.loglevel)


Cheers
    Rob
					
										

Re: [Wrapper-user] CPU Timeouts and JVM Restarts

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

Mitch,
Version 3.1.1 introduced a new tick based timer which handles heavy loads
much more reliably. It was in 3.1.0 as an experimental feature but had a few
critical bugs.

Upgrade to 3.1.1 and then set the new "wrapper.use_system_timeout=false"
property. See the docs for details:
http://wrapper.tanukisoftware.org/doc/english/prop-use-system-time.html

After receiving more feadback on the reliability of the new tick based timer
from users running on various platforms and environments, the goal is to
make
this new timer the default for future versions of the Wrapper. From my
tests,
it has proved to be much more reliable. The differences between the two
timers are all described in the above docs.

As Paul said, the restarting features are actually very good to have enabled
in the long term. They will save you lots of headaches and worries if your
application every begins having reliability problems. Even with the system
time based timer, there are ways of avoiding restarts by extending (not
disabling)
the various timeouts as Sal mentioned.

Cheers,
Leif


Mi...@bo... wrote:

> I'm currently using v3.1.0 of the wrapper, and I haven't had too many
> problems with it. However, I am now running into a problem where the
> wrapper thinks that my JVM has hung and does an automatic restart. I
> get "Wrapper Process has not received any CPU time for 38 seconds.
> Extending timeouts." and immediately following that I get a JVM restart.
> My service is running on machines that experience heavy load, and my
> service itself is a fairly large multi-threaded application that will
> produce its own heavy load. I would rather attempt to "ignore" the
> whole CPU/Ping etc. timeout values because I don't want my JVM to be
> automatically restarted. What is the best way to set all of the
> timeout/interval configuration parameters so that I can ignore these
> checks, and deal with the consequences of a "hung" JVM with a manual
> intervention?
> Thanks,
> Mitch

RE: [Wrapper-user] CPU Timeouts and JVM Restarts

[<Mi...@bo...>]

Thanks all for the help! I'll play around with the timeouts and see what I
come up with.

Thanks,

Mitch

-----Original Message-----
From: Paul Casanova [mailto:cas...@au...] 
Sent: Monday, July 26, 2004 6:25 PM
To: wra...@li...
Subject: RE: [Wrapper-user] CPU Timeouts and JVM Restarts






I had a similar issue with the JVM timing out, and found that setting the
Xms and Xmx parameters to different values (they were both 1600M initially)
overcame the JVM timeout problem.

I too was hesitant about having the JSW restarting the JVM, but have found
that it's a God send - saves our client logging a problem with the helpdesk
etc, because by the time that they do, the application is well on it's way
to being fully started.

Hope this is of some use.

Paul Casanova.

you could try this:
wrapper.startup.timeout=0 (def = 30 sec)
wrapper.ping.timeout=0 (def = 30 sec)
wrapper.cpu.timeout=3600 (def = 10 sec)

there are other timeout values.  check out the docs:
http://wrapper.tanukisoftware.org/doc/english/properties.html
      -----Original Message-----
      From: wra...@li...
      [mailto:wra...@li...]On Behalf Of
      Mi...@bo...
      Sent: Monday, July 26, 2004 12:56 PM
      To: wra...@li...
      Subject: [Wrapper-user] CPU Timeouts and JVM Restarts

      I'm currently using v3.1.0 of the wrapper, and I haven't had too many
      problems with it. However, I am now running into a problem where the
      wrapper thinks that my JVM has hung and does an automatic restart. I
      get "Wrapper Process has not received any CPU time for 38 seconds.
      Extending timeouts." and immediately following that I get a JVM
      restart.

      My service is running on machines that experience heavy load, and my
      service itself is a fairly large multi-threaded application that will
      produce its own heavy load. I would rather attempt to "ignore" the
      whole CPU/Ping etc. timeout values because I don't want my JVM to be
      automatically restarted. What is the best way to set all of the
      timeout/interval configuration parameters so that I can ignore these
      checks, and deal with the consequences of a "hung" JVM with a manual
      intervention?

      Thanks,

      Mitch



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

RE: [Wrapper-user] CPU Timeouts and JVM Restarts

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

I had a similar issue with the JVM timing out, and found that setting the
Xms and Xmx parameters to different values (they were both 1600M initially)
overcame the JVM timeout problem.

I too was hesitant about having the JSW restarting the JVM, but have found
that it's a God send - saves our client logging a problem with the helpdesk
etc, because by the time that they do, the application is well on it's way
to being fully started.

Hope this is of some use.

Paul Casanova.

you could try this:
wrapper.startup.timeout=0 (def = 30 sec)
wrapper.ping.timeout=0 (def = 30 sec)
wrapper.cpu.timeout=3600 (def = 10 sec)

there are other timeout values.  check out the docs:
http://wrapper.tanukisoftware.org/doc/english/properties.html
      -----Original Message-----
      From: wra...@li...
      [mailto:wra...@li...]On Behalf Of
      Mi...@bo...
      Sent: Monday, July 26, 2004 12:56 PM
      To: wra...@li...
      Subject: [Wrapper-user] CPU Timeouts and JVM Restarts

      I'm currently using v3.1.0 of the wrapper, and I haven't had too many
      problems with it. However, I am now running into a problem where the
      wrapper thinks that my JVM has hung and does an automatic restart. I
      get "Wrapper Process has not received any CPU time for 38 seconds.
      Extending timeouts." and immediately following that I get a JVM
      restart.

      My service is running on machines that experience heavy load, and my
      service itself is a fairly large multi-threaded application that will
      produce its own heavy load. I would rather attempt to "ignore" the
      whole CPU/Ping etc. timeout values because I don't want my JVM to be
      automatically restarted. What is the best way to set all of the
      timeout/interval configuration parameters so that I can ignore these
      checks, and deal with the consequences of a "hung" JVM with a manual
      intervention?

      Thanks,

      Mitch

RE: [Wrapper-user] CPU Timeouts and JVM Restarts

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

Messageyou could try this:
wrapper.startup.timeout=0 (def = 30 sec)
wrapper.ping.timeout=0 (def = 30 sec)
wrapper.cpu.timeout=3600 (def = 10 sec)

there are other timeout values.  check out the docs:
http://wrapper.tanukisoftware.org/doc/english/properties.html
  -----Original Message-----
  From: wra...@li...
[mailto:wra...@li...]On Behalf Of
Mi...@bo...
  Sent: Monday, July 26, 2004 12:56 PM
  To: wra...@li...
  Subject: [Wrapper-user] CPU Timeouts and JVM Restarts


  I'm currently using v3.1.0 of the wrapper, and I haven't had too many
problems with it. However, I am now running into a problem where the wrapper
thinks that my JVM has hung and does an automatic restart. I get "Wrapper
Process has not received any CPU time for 38 seconds. Extending timeouts."
and immediately following that I get a JVM restart.

  My service is running on machines that experience heavy load, and my
service itself is a fairly large multi-threaded application that will
produce its own heavy load. I would rather attempt to "ignore" the whole
CPU/Ping etc. timeout values because I don't want my JVM to be automatically
restarted. What is the best way to set all of the timeout/interval
configuration parameters so that I can ignore these checks, and deal with
the consequences of a "hung" JVM with a manual intervention?

  Thanks,

  Mitch

[Wrapper-user] CPU Timeouts and JVM Restarts

[<Mi...@bo...>]

I'm currently using v3.1.0 of the wrapper, and I haven't had too many
problems with it. However, I am now running into a problem where the wrapper
thinks that my JVM has hung and does an automatic restart. I get "Wrapper
Process has not received any CPU time for 38 seconds. Extending timeouts."
and immediately following that I get a JVM restart.
 
My service is running on machines that experience heavy load, and my service
itself is a fairly large multi-threaded application that will produce its
own heavy load. I would rather attempt to "ignore" the whole CPU/Ping etc.
timeout values because I don't want my JVM to be automatically restarted.
What is the best way to set all of the timeout/interval configuration
parameters so that I can ignore these checks, and deal with the consequences
of a "hung" JVM with a manual intervention?
 
Thanks,
 
Mitch

RE: [Wrapper-user] JBoss 3.2.2 logging problems

[Fuechsel, A. <And...@at...>]

Sal Ingrilli wrote:
> when the system is starting / stopping it uses the
> jboss/server/default/conf/log4j.xml / properties to control logging.
> however, if one of your apps deployed in jboss/server/default/deploy
> contains a log4j.jar / lo4j.xml / log4j.properties, it may take over
> the initial logger used for bootup. that will behave differently
> depending of whether you have setup a jboss loader repository in your
> jboss-serverice.xml in your jar/war/ear/sar/xml:

Thanks! Exactly what you are describing first was the reason: I made a
mistake in the my Ant build.xml and got another log4j.xml deployed with
wrong logging level settings. I removed it and everything now works as
expected. Thanks for your help!

Andr=E9

RE: [Wrapper-user] JBoss 3.2.2 logging problems

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

JBoss 3.2.2 logging problemswhen the system is starting / stopping it uses
the jboss/server/default/conf/log4j.xml / properties to control logging.
however, if one of your apps deployed in jboss/server/default/deploy
contains a log4j.jar / lo4j.xml / log4j.properties, it may take over the
initial logger used for bootup.
that will behave differently depending of whether you have setup a jboss
loader repository in your jboss-serverice.xml in your jar/war/ear/sar/xml:
<loader-repository>jboss.loader.repository:sar=support-watchdog.sar</loader-
repository>
when jboss stops, it undeployes your app, and hence your logger.  at this
point, it reverts to the /conf logger (the bootup logger), which logs
differently than your logger.
that's why you can see the shutdown being logged.
so this perfectly explains your situation: just take a look at what you are
deploying.
remember that jboss uses a class loader hierarchy.  you can read about in
the jboss docs to better understand how it affects your app.

if it's still happens, i have only one more idea:
i have a couple of tools that log a LOT to the console.
that's System.out.println () calls which are in turn stdout calls.
after a while my program runs, windows/log4j decides that it's not going to
print out stdout calls anymore.
i don't know why they does that, but i can tell you that that's NOT the
wrapper.

now try changing your your wrapper.console.loglevel=INFO to
wrapper.console.loglevel=DEBUG and see if it's any better.

good luck.
  -----Original Message-----
  From: wra...@li...
[mailto:wra...@li...]On Behalf Of Fuechsel,
Andre
  Sent: Friday, July 23, 2004 1:01 AM
  To: 'wra...@li...'
  Subject: [Wrapper-user] JBoss 3.2.2 logging problems


  Hi,

  I set up my JBoss 3.2.2 with the wrapper_win32_3.1.1 and everything works
well except the logging. Running the JBoss.bat script everything works as
expected and I get all the JBoss loggings as configured in the configuration
file${jboss.home}/server/myserver/conf/log4j.xml.

  But having JBoss now installed as a Windows service, the logging behaviour
is very strange:

  The startup process is logged correctly both in wrapper.log and in
server.log from JBoss.

  After the server has been started, nothing else is logged in both files
(the last line is the usual

  INFO   | jvm 1    | 2004/07/22 14:07:07 | 14:07:07,221 INFO  [Server]
JBoss (MX MicroKernel) [3.2.2 (build: CVSTag=JBoss_3_2_2 date=200310182216)]
Started in 3m:49s:941ms

  The shutdown process is logged again as usual.

  Any ideas where the other logs are going to? This is my configuration:

  wrapper.console.format=PM
  wrapper.console.loglevel=INFO
  wrapper.logfile=..\logs\wrapper.log
  wrapper.logfile.format=LPTM
  wrapper.logfile.loglevel=INFO
  wrapper.logfile.maxsize=1m
  wrapper.logfile.maxfiles=50
  wrapper.syslog.loglevel=STATUS

  Thanks in advance.

  André

[Wrapper-user] JBoss 3.2.2 logging problems

[Fuechsel, A. <And...@at...>]

Hi,=20

I set up my JBoss 3.2.2 with the wrapper_win32_3.1.1 and everything =
works
well except the logging. Running the JBoss.bat script everything works =
as
expected and I get all the JBoss loggings as configured in the =
configuration
file${jboss.home}/server/myserver/conf/log4j.xml.=20

But having JBoss now installed as a Windows service, the logging =
behaviour
is very strange:=20

The startup process is logged correctly both in wrapper.log and in
server.log from JBoss.=20

After the server has been started, nothing else is logged in both files =
(the
last line is the usual=20

INFO   | jvm 1    | 2004/07/22 14:07:07 | 14:07:07,221 INFO  [Server] =
JBoss
(MX MicroKernel) [3.2.2 (build: CVSTag=3DJBoss_3_2_2 =
date=3D200310182216)]
Started in 3m:49s:941ms

The shutdown process is logged again as usual.=20

Any ideas where the other logs are going to? This is my configuration:=20

wrapper.console.format=3DPM
wrapper.console.loglevel=3DINFO
wrapper.logfile=3D..\logs\wrapper.log
wrapper.logfile.format=3DLPTM
wrapper.logfile.loglevel=3DINFO
wrapper.logfile.maxsize=3D1m
wrapper.logfile.maxfiles=3D50
wrapper.syslog.loglevel=3DSTATUS

Thanks in advance.=20

Andr=E9

Re: [Wrapper-user] Wrapper stopping abruptly

[Sean S. <sea...@gm...>]

Leif,

Thanks for taking the time to look at the attachment.    My main
method did little else then check for a connection and return a
recordset.  I am now adding a thread that will continuously check the
db on an ongoing basis.  Everything seems to be working well with the
new structure and the wrapper is performing beautifully.

Hopefully the install as a service will go on smoothly.

Thanks,

Sean

On Thu, 22 Jul 2004 22:51:55 +0900, Leif Mortenson
<le...@ta...> wrote:
> Sean,
> Thanks for the log. As I thought, your application is exiting because
> all of its
> non-daemon threads have completed:
> INFO | jvm 1 | 2004/07/22 08:34:31 | All non-daemon threads have
> stopped. Exiting.
> 
> Your main method completes almost instantly about 3 seconds earlier. I
> have no way
> of knowing what your main method does. Make sure that at least one
> thread that it
> spawns off is a non daemon thread which does not complete until the
> application is
> ready to shutdown.
> 
> The program should also exit when running standalone as the JVM has the same
> logic to decide when to shutdown the JVM.
> 
> 
> 
> Cheers,
> Leif
> 
> Sean Scott wrote:
> 
> >Leif,
> >
> >Here is the attachment of the log file you requested with debugging turned on.
> >
> >Let me know if the exit was an expected result or not.
> >
> >BTW the java application being wrapper had done its job correctly.  I
> >just wanted to understand a little better how the wrapper determines
> >whether it should terminate itself or not.
> >
> >On Thu, 22 Jul 2004 08:54:15 +0900, Leif Mortenson
> ><le...@ta...> wrote:
> >
> >
> >>Sean,
> >>    The Wrapper is designed to use basically the same logic as the JVM
> >>to decide when
> >>to exit.   Once all non-daemon threads have terminated, the program is
> >>determined to
> >>have run to completion.
> >>
> >>    There are other reasons why the application could be exiting.  I
> >>would need to see the
> >>debug output of the Wrapper to determine exactly why your application is
> >>exiting.
> >>Set the wrapper.debug=true property in your wrapper.conf file and rerun
> >>it.  Then post
> >>back by attaching the wrapper.log for a single run of the JVM.   (Attach
> >>the file rather than
> >>including it in the body of the message to avoid any reformatting of the
> >>file)
> >>
> >>Cheers,
> >>Leif
> >>
> >>
> >>
> >>Sean Scott wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>Just wanted to know if it was common for the wrapper to stop abruply.
> >>>I am currently using integration method 1.  When i test my java applet
> >>>using the command console, everything works fine, it goes through the
> >>>apprpriate steps and outputs to the command.  However after a second
> >>>or two after the Java program is done doing its task the wrapper will
> >>>stop itself.
> >>>
> >>>Right now my java program opens a connection to a DB, and retrieves some rows.
> >>>
> >>>Wanted to know if this was expected behavior.
> >>>
> >>>The goal is to have a webservice that will continously monitor a DB
> >>>table every n seconds.
> >>>
> >>>Sean
> >>>
> >>>
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Wrapper stopping abruptly

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

Sean,
Thanks for the log. As I thought, your application is exiting because
all of its
non-daemon threads have completed:
INFO | jvm 1 | 2004/07/22 08:34:31 | All non-daemon threads have
stopped. Exiting.

Your main method completes almost instantly about 3 seconds earlier. I
have no way
of knowing what your main method does. Make sure that at least one
thread that it
spawns off is a non daemon thread which does not complete until the
application is
ready to shutdown.

The program should also exit when running standalone as the JVM has the same
logic to decide when to shutdown the JVM.

Cheers,
Leif

Sean Scott wrote:

>Leif,
>
>Here is the attachment of the log file you requested with debugging turned on.
>
>Let me know if the exit was an expected result or not.
>
>BTW the java application being wrapper had done its job correctly.  I
>just wanted to understand a little better how the wrapper determines
>whether it should terminate itself or not.
>
>On Thu, 22 Jul 2004 08:54:15 +0900, Leif Mortenson
><le...@ta...> wrote:
>  
>
>>Sean,
>>    The Wrapper is designed to use basically the same logic as the JVM
>>to decide when
>>to exit.   Once all non-daemon threads have terminated, the program is
>>determined to
>>have run to completion.
>>
>>    There are other reasons why the application could be exiting.  I
>>would need to see the
>>debug output of the Wrapper to determine exactly why your application is
>>exiting.
>>Set the wrapper.debug=true property in your wrapper.conf file and rerun
>>it.  Then post
>>back by attaching the wrapper.log for a single run of the JVM.   (Attach
>>the file rather than
>>including it in the body of the message to avoid any reformatting of the
>>file)
>>
>>Cheers,
>>Leif
>>
>>
>>
>>Sean Scott wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>Just wanted to know if it was common for the wrapper to stop abruply.
>>>I am currently using integration method 1.  When i test my java applet
>>>using the command console, everything works fine, it goes through the
>>>apprpriate steps and outputs to the command.  However after a second
>>>or two after the Java program is done doing its task the wrapper will
>>>stop itself.
>>>
>>>Right now my java program opens a connection to a DB, and retrieves some rows.
>>>
>>>Wanted to know if this was expected behavior.
>>>
>>>The goal is to have a webservice that will continously monitor a DB
>>>table every n seconds.
>>>
>>>Sean
>>>      
>>>