You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(16) |
Dec
(29) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(38) |
Feb
(51) |
Mar
(51) |
Apr
(115) |
May
(82) |
Jun
(30) |
Jul
(50) |
Aug
(68) |
Sep
(57) |
Oct
(160) |
Nov
(80) |
Dec
(78) |
| 2004 |
Jan
(71) |
Feb
(75) |
Mar
(108) |
Apr
(87) |
May
(79) |
Jun
(70) |
Jul
(69) |
Aug
(39) |
Sep
(52) |
Oct
(47) |
Nov
(50) |
Dec
(32) |
| 2005 |
Jan
(22) |
Feb
(122) |
Mar
(46) |
Apr
(76) |
May
(31) |
Jun
(51) |
Jul
(61) |
Aug
(70) |
Sep
(37) |
Oct
(46) |
Nov
(57) |
Dec
(83) |
| 2006 |
Jan
(55) |
Feb
(81) |
Mar
(51) |
Apr
(67) |
May
(77) |
Jun
(43) |
Jul
(106) |
Aug
(64) |
Sep
(47) |
Oct
(64) |
Nov
(60) |
Dec
(12) |
| 2007 |
Jan
(50) |
Feb
(93) |
Mar
(49) |
Apr
(56) |
May
(40) |
Jun
(63) |
Jul
(40) |
Aug
(47) |
Sep
(54) |
Oct
(37) |
Nov
(54) |
Dec
(37) |
| 2008 |
Jan
(35) |
Feb
(39) |
Mar
(26) |
Apr
(14) |
May
(23) |
Jun
(51) |
Jul
(43) |
Aug
(26) |
Sep
(29) |
Oct
(31) |
Nov
(24) |
Dec
(16) |
| 2009 |
Jan
(21) |
Feb
(30) |
Mar
(74) |
Apr
(26) |
May
(26) |
Jun
(43) |
Jul
(23) |
Aug
(23) |
Sep
(15) |
Oct
(27) |
Nov
(37) |
Dec
(10) |
| 2010 |
Jan
(16) |
Feb
(28) |
Mar
(16) |
Apr
(45) |
May
(8) |
Jun
(68) |
Jul
(45) |
Aug
(44) |
Sep
(51) |
Oct
(7) |
Nov
(20) |
Dec
(21) |
| 2011 |
Jan
(14) |
Feb
(17) |
Mar
(7) |
Apr
(7) |
May
(48) |
Jun
(23) |
Jul
(5) |
Aug
(33) |
Sep
(22) |
Oct
(14) |
Nov
(14) |
Dec
(5) |
| 2012 |
Jan
|
Feb
(10) |
Mar
(12) |
Apr
(51) |
May
(10) |
Jun
(8) |
Jul
(14) |
Aug
(22) |
Sep
(9) |
Oct
(24) |
Nov
(14) |
Dec
(13) |
| 2013 |
Jan
(12) |
Feb
(4) |
Mar
(14) |
Apr
(19) |
May
(2) |
Jun
(5) |
Jul
(13) |
Aug
(10) |
Sep
(4) |
Oct
(11) |
Nov
(13) |
Dec
(2) |
| 2014 |
Jan
(3) |
Feb
(14) |
Mar
(5) |
Apr
(10) |
May
(10) |
Jun
(11) |
Jul
(10) |
Aug
(3) |
Sep
(13) |
Oct
(22) |
Nov
(14) |
Dec
(32) |
| 2015 |
Jan
(8) |
Feb
(2) |
Mar
(17) |
Apr
(1) |
May
(24) |
Jun
|
Jul
(4) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2016 |
Jan
(8) |
Feb
(6) |
Mar
(6) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(7) |
Aug
(6) |
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
| 2017 |
Jan
(9) |
Feb
(8) |
Mar
(6) |
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
(10) |
Sep
(8) |
Oct
|
Nov
(6) |
Dec
|
| 2018 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(9) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2019 |
Jan
(9) |
Feb
|
Mar
|
Apr
(10) |
May
(3) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2021 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2023 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <da...@sm...> - 2006-06-17 04:10:12
|
(sorry for the personal post - stupid webmail client) You mention that your servers logging output is truncated. I guess =20 this means that your server was forceably closed by the Wrapper. This =20 normally happens when the wrapper has been notified of the stopping, =20 but the actual app has not stopped within the expected time period. =20 Check out the .conf property wrapper.shutdown.timeout or possibly =20 consider calling WrapperManager.signalStopping(...) every few seconds. To further get an understanding on what is going on under the bonnet, set th= e wrapper.debug to TRUE and inspect the results wrapper log file. This =20 will tell you exactly why the wrapper has shut down your application, =20 and will give you a better idea on how to solve it. You could post it as well for us to see if we could help. Cheers, Davy Boy Out... Quoting "TEI...@te..." <TEI...@te...>: > > Thanks, David! > > I don't think that's the case. I'll try to draw it with more =20 > detail. I developed my application without Wrapper in mind in the =20 > first > instance. Lets call the first app "Server" and "Manager" would be =20 > the second one. > Server is an event driven application, there's an event queue from =20 > where it pops events. When a "shutdown" event is read, Server stops > reading events, asks avery of its working threads (non daemon =20 > threads) to stop (they will close connections) and waits until all =20 > of them > have stopped (this doesn't take more than 5s). > Server logs almost every meaningful event/action it takes. > > The whole system, running alone, outside the wrapper, would log =20 > something like this. > > 1. Server: Start > 2. Server: Launching a "connector" thread to handle incoming connection= s. > 3. Server: Trying to connect to other applications (more threads =20 > and connections) > ... > 4. Server: Receiving an incoming connection -> a worker thread is =20 > launched in order to handle it. > ... > At this moment a number of (non daemon) threads are running. > ... > 5. Manager: Connected to the server, sent a shutdown command, =20 > closed connection and finish. > 6. Server: ( ... keeps doing its thing ...) A "shutdown" =20 > command/event was read. > 7. Server: Ask avery single thread to stop (threads will close =20 > connections as soon as possible). > 8. Server: Wait for every single thread to stop. > 9. Server: Finish > > The whole system, running into the wrapper > > 1. Server: Start > 2. Server: Launching a "connector" thread to handle incoming connection= s. > 3. Server: Trying to connect to other applications - more threads =20 > and connections > ... > 4. Server: Receiving an incoming connection -> a worker thread is =20 > launched in order to handle it. > ... > At this moment a number of (non daemon) threads are running. > ... > 5. Manager: Connected to the server, sent a shutdown command, =20 > closed connection and finish. > 6. Server: ( ... keeps doing its thing ...) A "shutdown" =20 > command/event was read. > At this moment Manager is already dead and WrapperStartStopApp =20 > seems has decided to kill Server too, cause logging output was > truncated > > I added a Thread.sleep(5000) to make sure Manager's death was =20 > after Server's, the resulting logging output was the same as if the =20 > system > were running alone, that is, not into WrapperStartStopApp. > > Further comments, please! > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, =20 > r=E1pido, fiable. > > > > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: <TEI...@te...> - 2006-06-16 09:06:56
|
Thanks, David!
I don't think that's the case. I'll try to draw it with more detail. I de=
veloped my application without Wrapper in mind in the first=20
instance. Lets call the first app "Server" and "Manager" would be the secon=
d one.=20
Server is an event driven application, there's an event queue from where =
it pops events. When a "shutdown" event is read, Server stops=20
reading events, asks avery of its working threads (non daemon threads) to s=
top (they will close connections) and waits until all of them=20
have stopped (this doesn't take more than 5s).
Server logs almost every meaningful event/action it takes.
The whole system, running alone, outside the wrapper, would log something=
like this.
1. Server: Start=20
2. Server: Launching a "connector" thread to handle incoming connections=
.
3. Server: Trying to connect to other applications (more threads and con=
nections)
...
4. Server: Receiving an incoming connection -> a worker thread is launch=
ed in order to handle it.
...
At this moment a number of (non daemon) threads are running.
...
5. Manager: Connected to the server, sent a shutdown command, closed con=
nection and finish.
6. Server: ( ... keeps doing its thing ...) A "shutdown" command/event w=
as read.
7. Server: Ask avery single thread to stop (threads will close connectio=
ns as soon as possible).
8. Server: Wait for every single thread to stop.
9. Server: Finish
The whole system, running into the wrapper
1. Server: Start=20
2. Server: Launching a "connector" thread to handle incoming connections=
.
3. Server: Trying to connect to other applications - more threads and co=
nnections
...
4. Server: Receiving an incoming connection -> a worker thread is launch=
ed in order to handle it.
...
At this moment a number of (non daemon) threads are running.
...
5. Manager: Connected to the server, sent a shutdown command, closed con=
nection and finish.
6. Server: ( ... keeps doing its thing ...) A "shutdown" command/event w=
as read.
At this moment Manager is already dead and WrapperStartStopApp seems =
has decided to kill Server too, cause logging output was=20
truncated
I added a Thread.sleep(5000) to make sure Manager's death was after Serve=
r's, the resulting logging output was the same as if the system=20
were running alone, that is, not into WrapperStartStopApp.
Further comments, please!
Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r=C3=A1pido,=
fiable.
|
|
From: <da...@sm...> - 2006-06-15 18:02:29
|
I don't know about the Wrapper itself, but one of the things I found =20 with my network based app, was that I was waiting for all of my =20 network connections to be closed before I closed my app. I wonder if =20 it is the same thing here. It could be possible that your first app =20 doesn't fully stop the service, until all of the network connections =20 are closed, and that your second app opens the connection to the =20 first, sends the command it needs to send, but doesn't kill the =20 connection. What then happens is when your second app finally is =20 closed, the network connection drops, and the first app no longer has =20 an open connection, and finally it closes. It might not be the solution, but it is what happened with me, and it =20 may well be worth checking out what is happening. A useful command in =20 windows to see what ports and apps are being used is "netstat". Open a =20 command prompt, and do a netstat /? to see the options. I find netstat =20 -a -b useful. Hope this all helps! Davy Boy Out... Quoting "TEI...@te..." <TEI...@te...>: > Hi, all! > > I've developed a java application that runs as a windows service =20 > thanks to Wrapper and WrapperStartStopApp. > In order to shut down this application it is sent a message through =20 > a network connection from a second application. > This second application finishes its execution right after sending =20 > the shutdown command, so the first application continues its execution > for some time (seconds) while it cleanly shuts down (none of the =20 > threads it launches are daemon threads). > > I've noticed that WrapperStartStopApp kills my service right when =20 > the second application finishes its execution, not when the service > finishes by its own. > So, my questions are, is that the WrapperStartStopApp intended =20 > behavior? Am I missing any config params? ... > > Thanks in advance > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, =20 > r=E1pido, fiable. > > > > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: <TEI...@te...> - 2006-06-15 12:17:53
|
Hi, all! I've developed a java application that runs as a windows service thanks to = Wrapper and WrapperStartStopApp. In order to shut down this application it is sent a message through a netwo= rk connection from a second application.=20 This second application finishes its execution right after sending the shut= down command, so the first application continues its execution=20 for some time (seconds) while it cleanly shuts down (none of the threads it= launches are daemon threads). I've noticed that WrapperStartStopApp kills my service right when the secon= d application finishes its execution, not when the service=20 finishes by its own.=20 So, my questions are, is that the WrapperStartStopApp intended behavior? Am= I missing any config params? ... Thanks in advance Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r=C3=A1pido,= fiable. |
|
From: Leif M. <le...@ta...> - 2006-06-15 06:11:21
|
Dmitriy,
Where is ".\logs\status.txt"? Is it a network device by any
chance? The System user
does not have access to the network.
Cheers,
Leif
Dmitriy Yuriev wrote:
> David, thank you for your advice. I did change the properties file to
> use the same account that I was logged on with to run the service.
> Still not sure why the 'Local System' account doesn't work though,
> checked all of the file permissions and all files seem to be
> readable/writeable for all accounts. Kind of ponderous.
|
|
From: Dmitriy Y. <dy...@gm...> - 2006-06-15 05:13:04
|
David, thank you for your advice. I did change the properties file to use the same account that I was logged on with to run the service. Still not sure why the 'Local System' account doesn't work though, checked all of the file permissions and all files seem to be readable/writeable for all accounts. Kind of ponderous. |
|
From: David H. <da...@sm...> - 2006-06-14 17:43:43
|
Dmitriy,
Taken from recent post from Leif:
If that looks correct, my guess would be that you have installed some
permissions on the directory where the wrapper.exe is located which are
preventing the system account from even seeing that file.
Unless you have specified an account in your wrapper.conf file, the Wrapper
will normally run as the SYSTEM account when running as a service. This is
different from the account you are logged in as and thus run as when in
console mode.
I believe the same thing is happening here. Unless you have specifically set
a user for the app to run under, it runs as SYSTEM, whereas your -c runs the
app as the current user. Try changing the conf file to use a different user
who has the same rights as your current user, and see if that helps,
Davy Boy Out..
_____
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Dmitriy
Yuriev
Sent: 14 June 2006 01:36
To: wra...@li...
Subject: [Wrapper-user] Access is denied while attempting to write to a file
Greetings.
I am configuring CruiseControl to run as a service with wrapper. Service
itself seems to start ok, but when CruiseControl tries to update some files
I get the following exception (see below).
If I start CruiseControl through a command prompt, it works fine. If I start
it through wrapper using '-c' option (run as a Console application) it works
fine as well, the error only happens running it through the service. Thanks
in advance.
2006-06-13 22:22:17,977 [WrapperSimpleAppMain] ERROR Project -
exception notifying listener
net.sourceforge.cruisecontrol.listeners.CurrentBuildStatusListener for
project AM
net.sourceforge.cruisecontrol.CruiseControlException : Error writing file:
.\logs\status.txt : .\logs\status.txt (Access is denied)
at
net.sourceforge.cruisecontrol.util.CurrentBuildFileWriter.writefile(CurrentB
uildFileWriter.java:68)
at
net.sourceforge.cruisecontrol.listeners.CurrentBuildStatusListener.handleEve
nt (CurrentBuildStatusListener.java:33)
at
net.sourceforge.cruisecontrol.Project.notifyListeners(Project.java:828)
at net.sourceforge.cruisecontrol.Project.setState(Project.java:573)
at net.sourceforge.cruisecontrol.Project.start (Project.java:751)
at
net.sourceforge.cruisecontrol.CruiseControlController.addProject(CruiseContr
olController.java:119)
at
net.sourceforge.cruisecontrol.CruiseControlController.loadConfigFromConfigMa
nager(CruiseControlController.java :292)
at
net.sourceforge.cruisecontrol.CruiseControlController.setConfigFile(CruiseCo
ntrolController.java:100)
at net.sourceforge.cruisecontrol.Main.main(Main.java:85)
at CruiseControl.main(CruiseControl.java :57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java:197)
|
|
From: William P. <wp...@be...> - 2006-06-14 16:08:26
|
You were absolutely right: the service ran as a different user with different permissions than when wrapper.exe launched the application using the console, and that was, in the end, the culprit. Thanks, everybody, for chiming in. I really appreciate the help. - Bill -----Original Message----- From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson Sent: Tuesday, June 13, 2006 8:34 PM To: wra...@li... Subject: Re: [Wrapper-user] App runs as console but not service William, The "Unable to start the service" message is coming from the Wrapper=20 when it attempts to launch your service via the ServiceManager. The rest of the message=20 is coming from the ServiceManager. Could you bring up your Services Control Panel window and look at the=20 service that you installed? Are you able to start the service from the control panel? If you bring up the properties of the service, what is the full command=20 that is shown? For example: D:\SourceForge\wrapper\bin\wrapper.exe -s=20 D:\SourceForge\wrapper\conf\wrapper.conf If that looks correct, my guess would be that you have installed some=20 permissions on the directory where the wrapper.exe is located which are preventing the=20 system account from even seeing that file. Unless you have specified an account in your wrapper.conf file, the=20 Wrapper will normally run as the SYSTEM account when running as a service. This is=20 different from the account you are logged in as and thus run as when in console mode. Cheers, Leif William Press wrote: > > Greetings, > > I'm using Tanuki 3.1.2 to install a service with Tomcat 5.0.28 and JRE > 1.4.2 on Windows Server 2003. > > When I install the service using > > wrapper.exe -i C:\foo\bar\wrapper.conf > > it successfully installs the service in my Service Manager. However,=20 > when I try to start the service, either using the service manager=20 > (which uses the -s flag) or from the console with > > wrapper.exe -t C:\foo\bar\wrapper.conf > > I get the message > > [exec] wrapper | Unable to start the service - The system cannot find=20 > the path specified. (0x3) > > and not much else. > > Now the interesting part: when I run the service from the console, using > > wrapper.exe -c C:\foo\bar\wrapper.conf > > it runs without problem. > > The platform, library paths, etc, are all set properly in wrapper.conf > (confirmed by its running successfully with -c). Also, my shell has=20 > the same environment variables as my system. > > Enabling the debug flag in wrapper.conf doesn't give any more output=20 > when it errors out, though the successful -c run is more chatty, so I=20 > know it picks up the flag. Tracking the filesystem activity with=20 > FileMon doesn't show anything untoward, and RegMon is too chatty to=20 > make anything of, but I've scrubbed my registry of "tomcat" and=20 > "catalina" in case any previous installations of Tomcat (since=20 > removed) might be bunging up the works. > > Any thoughts as to what might be going on and how I might fix it would > be greatly appreciated. > > Thanks, > > Bill > _______________________________________________ Wrapper-user mailing list Wra...@li... https://lists.sourceforge.net/lists/listinfo/wrapper-user _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |
|
From: Dmitriy Y. <dy...@gm...> - 2006-06-14 05:36:02
|
Greetings.
I am configuring CruiseControl to run as a service with wrapper. Service
itself seems to start ok, but when CruiseControl tries to update some files
I get the following exception (see below).
If I start CruiseControl through a command prompt, it works fine. If I start
it through wrapper using '-c' option (run as a Console application) it works
fine as well, the error only happens running it through the service. Thanks
in advance.
2006-06-13 22:22:17,977 [WrapperSimpleAppMain] ERROR Project -
exception notifying listener
net.sourceforge.cruisecontrol.listeners.CurrentBuildStatusListener for
project AM
net.sourceforge.cruisecontrol.CruiseControlException: Error writing file:
.\logs\status.txt : .\logs\status.txt (Access is denied)
at net.sourceforge.cruisecontrol.util.CurrentBuildFileWriter.writefile(
CurrentBuildFileWriter.java:68)
at
net.sourceforge.cruisecontrol.listeners.CurrentBuildStatusListener.handleEvent
(CurrentBuildStatusListener.java:33)
at net.sourceforge.cruisecontrol.Project.notifyListeners(Project.java
:828)
at net.sourceforge.cruisecontrol.Project.setState(Project.java:573)
at net.sourceforge.cruisecontrol.Project.start(Project.java:751)
at net.sourceforge.cruisecontrol.CruiseControlController.addProject(
CruiseControlController.java:119)
at
net.sourceforge.cruisecontrol.CruiseControlController.loadConfigFromConfigManager
(CruiseControlController.java:292)
at net.sourceforge.cruisecontrol.CruiseControlController.setConfigFile(
CruiseControlController.java:100)
at net.sourceforge.cruisecontrol.Main.main(Main.java:85)
at CruiseControl.main(CruiseControl.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java
:197)
|
|
From: Leif M. <le...@ta...> - 2006-06-14 03:33:25
|
William, The "Unable to start the service" message is coming from the Wrapper when it attempts to launch your service via the ServiceManager. The rest of the message is coming from the ServiceManager. Could you bring up your Services Control Panel window and look at the service that you installed? Are you able to start the service from the control panel? If you bring up the properties of the service, what is the full command that is shown? For example: D:\SourceForge\wrapper\bin\wrapper.exe -s D:\SourceForge\wrapper\conf\wrapper.conf If that looks correct, my guess would be that you have installed some permissions on the directory where the wrapper.exe is located which are preventing the system account from even seeing that file. Unless you have specified an account in your wrapper.conf file, the Wrapper will normally run as the SYSTEM account when running as a service. This is different from the account you are logged in as and thus run as when in console mode. Cheers, Leif William Press wrote: > > Greetings, > > I’m using Tanuki 3.1.2 to install a service with Tomcat 5.0.28 and JRE > 1.4.2 on Windows Server 2003. > > When I install the service using > > wrapper.exe –i C:\foo\bar\wrapper.conf > > it successfully installs the service in my Service Manager. However, > when I try to start the service, either using the service manager > (which uses the –s flag) or from the console with > > wrapper.exe –t C:\foo\bar\wrapper.conf > > I get the message > > [exec] wrapper | Unable to start the service - The system cannot find > the path specified. (0x3) > > and not much else. > > Now the interesting part: when I run the service from the console, using > > wrapper.exe –c C:\foo\bar\wrapper.conf > > it runs without problem. > > The platform, library paths, etc, are all set properly in wrapper.conf > (confirmed by its running successfully with –c). Also, my shell has > the same environment variables as my system. > > Enabling the debug flag in wrapper.conf doesn’t give any more output > when it errors out, though the successful –c run is more chatty, so I > know it picks up the flag. Tracking the filesystem activity with > FileMon doesn’t show anything untoward, and RegMon is too chatty to > make anything of, but I’ve scrubbed my registry of “tomcat” and > “catalina” in case any previous installations of Tomcat (since > removed) might be bunging up the works. > > Any thoughts as to what might be going on and how I might fix it would > be greatly appreciated. > > Thanks, > > Bill > |
|
From: David H. <da...@sm...> - 2006-06-14 02:18:25
|
Can you post your wrapper.conf file, and the log file it produces, it gives us all a better idea of what is going on under the bonnet, especially the Debug version. Cheers, Davy Boy Out. _____ From: wra...@li... [mailto:wra...@li...] On Behalf Of William Press Sent: 13 June 2006 13:36 To: wra...@li... Subject: [Wrapper-user] App runs as console but not service Greetings, I'm using Tanuki 3.1.2 to install a service with Tomcat 5.0.28 and JRE 1.4.2 on Windows Server 2003. When I install the service using wrapper.exe -i C:\foo\bar\wrapper.conf it successfully installs the service in my Service Manager. However, when I try to start the service, either using the service manager (which uses the -s flag) or from the console with wrapper.exe -t C:\foo\bar\wrapper.conf I get the message [exec] wrapper | Unable to start the service - The system cannot find the path specified. (0x3) and not much else. Now the interesting part: when I run the service from the console, using wrapper.exe -c C:\foo\bar\wrapper.conf it runs without problem. The platform, library paths, etc, are all set properly in wrapper.conf (confirmed by its running successfully with -c). Also, my shell has the same environment variables as my system. Enabling the debug flag in wrapper.conf doesn't give any more output when it errors out, though the successful -c run is more chatty, so I know it picks up the flag. Tracking the filesystem activity with FileMon doesn't show anything untoward, and RegMon is too chatty to make anything of, but I've scrubbed my registry of "tomcat" and "catalina" in case any previous installations of Tomcat (since removed) might be bunging up the works. Any thoughts as to what might be going on and how I might fix it would be greatly appreciated. Thanks, Bill |
|
From: William P. <wp...@be...> - 2006-06-13 17:36:37
|
Greetings, =20 I'm using Tanuki 3.1.2 to install a service with Tomcat 5.0.28 and JRE 1.4.2 on Windows Server 2003. =20 When I install the service using =20 wrapper.exe -i C:\foo\bar\wrapper.conf =20 it successfully installs the service in my Service Manager. However, when I try to start the service, either using the service manager (which uses the -s flag) or from the console with =20 wrapper.exe -t C:\foo\bar\wrapper.conf =20 I get the message=20 =20 [exec] wrapper | Unable to start the service - The system cannot find the path specified. (0x3) =20 and not much else. =20 Now the interesting part: when I run the service from the console, using =20 wrapper.exe -c C:\foo\bar\wrapper.conf =20 it runs without problem. =20 The platform, library paths, etc, are all set properly in wrapper.conf (confirmed by its running successfully with -c). Also, my shell has the same environment variables as my system. =20 Enabling the debug flag in wrapper.conf doesn't give any more output when it errors out, though the successful -c run is more chatty, so I know it picks up the flag. Tracking the filesystem activity with FileMon doesn't show anything untoward, and RegMon is too chatty to make anything of, but I've scrubbed my registry of "tomcat" and "catalina" in case any previous installations of Tomcat (since removed) might be bunging up the works. =20 Any thoughts as to what might be going on and how I might fix it would be greatly appreciated. =20 Thanks, Bill=20 |
|
From: Joost J. <jj...@fi...> - 2006-06-09 07:34:26
|
Maybe it is even possible to sent it through the wrapperListener as a control event.
But at least the application should be implement the code to handle it.
In my case ( as I replied but it made a new thread about it) it would stop handling incoming messages but keeps other incoming messages in a queue.
This is useful because the service should only be stopped in case of an emergency and then clear the queue. But if some data needs to be changed the service needs to be paused while the older data needs to remain.
So it would definitely be a useful feature, perhaps through a setting in the configuration file (with a default to disabled).
Greetings,
Joost
-----Original Message-----
I also thought about this, but as I love the program too much, I didn't feel
I had the right to complain or find things wrong! :-)
The paused state is a useful feature. Obviously the difficult part is not
from the wrapper side of things, but from the end application. It must be
able to listen to an ActionEvent (mebe?) from the Wrapper, notifying it of
the paused state (or resumed state), carry out the necessary work to pause
the required sections of the application, and then notify the wrapper of the
completion of the application in paused/resumed mode.
>From our apps, the concept of pausing/resuming can be more complex than the
shutdown. That said, it would be a highly useful addition to the Wrapper.
Cheers Leif!
Davy Boy
-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: 07 June 2006 03:52
To: wra...@li...
Subject: Re: [Wrapper-user] How do I enable pause and resume on a service
Joost,
The way the Wrapper is registered as a service, the pause and resume
features are being
intentionally disabled. This is because it is not really possible to
"pause" a Java applicaiton.
You currently have to completely stop the service.
Could you explain what you are trying to do and let me know why a
pause would be
better than completely stopping the service. When paused, what state
would you
expect your app to be in?
Cheers,
Leif
Joost Jens wrote:
> > Hello,
> >
> > I have started using the service and it does wonders for me.
> >
> > But my question is:
> > How can I enable the pause and resume buttons for the service. Because
> > they are both disabled when I have started the service.
> >
> > I hope you guys can help me.
> >
> > With kind regards,
> > Joost Jens
>
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
|
|
From: David H. <da...@sm...> - 2006-06-08 13:18:52
|
I also thought about this, but as I love the program too much, I didn't feel
I had the right to complain or find things wrong! :-)
The paused state is a useful feature. Obviously the difficult part is not
from the wrapper side of things, but from the end application. It must be
able to listen to an ActionEvent (mebe?) from the Wrapper, notifying it of
the paused state (or resumed state), carry out the necessary work to pause
the required sections of the application, and then notify the wrapper of the
completion of the application in paused/resumed mode.
>From our apps, the concept of pausing/resuming can be more complex than the
shutdown. That said, it would be a highly useful addition to the Wrapper.
Cheers Leif!
Davy Boy
-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: 07 June 2006 03:52
To: wra...@li...
Subject: Re: [Wrapper-user] How do I enable pause and resume on a service
Joost,
The way the Wrapper is registered as a service, the pause and resume
features are being
intentionally disabled. This is because it is not really possible to
"pause" a Java applicaiton.
You currently have to completely stop the service.
Could you explain what you are trying to do and let me know why a
pause would be
better than completely stopping the service. When paused, what state
would you
expect your app to be in?
Cheers,
Leif
Joost Jens wrote:
> Hello,
>
> I have started using the service and it does wonders for me.
>
> But my question is:
> How can I enable the pause and resume buttons for the service. Because
> they are both disabled when I have started the service.
>
> I hope you guys can help me.
>
> With kind regards,
> Joost Jens
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
|
|
From: David F. <dav...@zi...> - 2006-06-07 17:25:56
|
I think I found the answer to my question regarding detection of 64bit JVM. If anyone has a better solution, do tell. Seems Sun has a Java System property to determine the bitness of the JVM: 32 or 64: sun.arch.data.model=32 // 32 bit JVM sun.arch.data.model=64 // 64 bit JVM As with any proprietary System property, it may only work on Sun's JVM (ie: not IBM's). It may disappear in the future... Regards, David On Jun 7, 2006, at 12:15 PM, David Ferrero wrote: > Thanks Leif, but I think I wasn't clear enough in my first post. > > I am trying to build one installer that takes care of all java > supported OS / JVM possibilities. I have reviewed the testwrapper > shell script in the JWS bin directory. As I understand it, it works > as follows: > > By default it will use the 32 bit version of the wrapper binary. If > it can't find that, it will test for the 64 bit version (or in the > case of Mac OS X, the universal binary) and run that instead. If it > can't find either, it will display an error message. > > Please correct me if I'm wrong, but it would appear that it is my > software installer's responsibility to detect if the user is > installing on a 64-bit JVM. If both the 32 bit and 64 bit wrapper > binaries were present, that it would attempt to use the 32 bit > wrapper binary first and it would fail on a 64 bit JVM environment. > > Is there any way to detect if they are using a 64-bit JVM? I would > like to avoid having to display an error and requiring the user to > delete the 32-bit wrapper binary manually before restarting. Is > the best we can do to document the 64-bit JVM situation? > > Thanks for any clarity anyone can share about detecting 64-bit JVM > or the inner workings of JWS that I may be mistaken about. > > > >> From: Leif Mortenson <leif@ta...> >> >> <msg.gif> >> Re: getting hardware arch using just java >> 2006-06-07 00:54 >> David, >> The files in the delta pack can be deleted as you wish, or even >> added if you have >> compiled the wrapper for other platforms. In general, the >> wrapper-xx-xx-64 files >> are not really needed as the 32 bit versions work fine on the 64 bit >> platforms. >> The libwrapper-xx-xx-64.so files are required if a 64 bit JVM is >> being >> used. The >> 32.so files are used by 32 bit JVMs regardless of whether the >> hardware >> is 32 or >> 64 bits. >> >> Cheers, >> Leif >> >> David Ferrero wrote: >> > If I want the wrapper scripts to detect the proper architecture >> > native libs to use, and I want to minimize the installation >> size of >> > my software, can I have my installer script install just the OS >> bits >> > for a given OS instead of the whole delta-pack? >> > >> > ie: >> > >> > For os.name="Linux", could I have my Installer just copy the Linux >> > scripts plus the following files? >> > lib/wrapper.jar >> > lib/libwrapper-linux-ppc-64.so >> > lib/libwrapper-linux-x86-32.so >> > lib/libwrapper-linux-x86-64.so >> > >> > Thanks for clarifying, >> > >> > David >> > > > |
|
From: David F. <dav...@zi...> - 2006-06-07 16:15:24
|
Thanks Leif, but I think I wasn't clear enough in my first post. I am trying to build one installer that takes care of all java =20 supported OS / JVM possibilities. I have reviewed the testwrapper =20 shell script in the JWS bin directory. As I understand it, it works =20 as follows: By default it will use the 32 bit version of the wrapper binary. If =20 it can't find that, it will test for the 64 bit version (or in the =20 case of Mac OS X, the universal binary) and run that instead. If it =20 can't find either, it will display an error message. Please correct me if I'm wrong, but it would appear that it is my =20 software installer's responsibility to detect if the user is =20 installing on a 64-bit JVM. If both the 32 bit and 64 bit wrapper =20 binaries were present, that it would attempt to use the 32 bit =20 wrapper binary first and it would fail on a 64 bit JVM environment. Is there any way to detect if they are using a 64-bit JVM? I would =20 like to avoid having to display an error and requiring the user to =20 delete the 32-bit wrapper binary manually before restarting. Is the =20 best we can do to document the 64-bit JVM situation? Thanks for any clarity anyone can share about detecting 64-bit JVM or =20= the inner workings of JWS that I may be mistaken about. > From: Leif Mortenson <leif@ta...> > =EF=BF=BC Re: getting hardware arch using just java > 2006-06-07 00:54 > David, > The files in the delta pack can be deleted as you wish, or even > added if you have > compiled the wrapper for other platforms. In general, the > wrapper-xx-xx-64 files > are not really needed as the 32 bit versions work fine on the 64 bit > platforms. > The libwrapper-xx-xx-64.so files are required if a 64 bit JVM is =20 > being > used. The > 32.so files are used by 32 bit JVMs regardless of whether the =20 > hardware > is 32 or > 64 bits. > > Cheers, > Leif > > David Ferrero wrote: > > If I want the wrapper scripts to detect the proper architecture > > native libs to use, and I want to minimize the installation size of > > my software, can I have my installer script install just the OS =20 > bits > > for a given OS instead of the whole delta-pack? > > > > ie: > > > > For os.name=3D"Linux", could I have my Installer just copy the = Linux > > scripts plus the following files? > > lib/wrapper.jar > > lib/libwrapper-linux-ppc-64.so > > lib/libwrapper-linux-x86-32.so > > lib/libwrapper-linux-x86-64.so > > > > Thanks for clarifying, > > > > David > > |
|
From: Joost J. <jj...@fi...> - 2006-06-07 11:15:02
|
Hi Leif, I have written a server that is designed to put data in a database, and that server is running as a service. If for some reason the database needs some maintenance the server needs to be paused. So basically the java program is still running but the program is self should take the proper response on a pause and resume command. in my case it will simply not accept any more messages and connections. I hope I am a bit clear here. With kind regards, Joost Jens |
|
From: Leif M. <le...@ta...> - 2006-06-07 07:54:01
|
David,
The files in the delta pack can be deleted as you wish, or even
added if you have
compiled the wrapper for other platforms. In general, the
wrapper-xx-xx-64 files
are not really needed as the 32 bit versions work fine on the 64 bit
platforms.
The libwrapper-xx-xx-64.so files are required if a 64 bit JVM is being
used. The
32.so files are used by 32 bit JVMs regardless of whether the hardware
is 32 or
64 bits.
Cheers,
Leif
David Ferrero wrote:
> If I want the wrapper scripts to detect the proper architecture
> native libs to use, and I want to minimize the installation size of
> my software, can I have my installer script install just the OS bits
> for a given OS instead of the whole delta-pack?
>
> ie:
>
> For os.name="Linux", could I have my Installer just copy the Linux
> scripts plus the following files?
> lib/wrapper.jar
> lib/libwrapper-linux-ppc-64.so
> lib/libwrapper-linux-x86-32.so
> lib/libwrapper-linux-x86-64.so
>
> Thanks for clarifying,
>
> David
>
|
|
From: Leif M. <le...@ta...> - 2006-06-07 07:51:26
|
Joost,
The way the Wrapper is registered as a service, the pause and resume
features are being
intentionally disabled. This is because it is not really possible to
"pause" a Java applicaiton.
You currently have to completely stop the service.
Could you explain what you are trying to do and let me know why a
pause would be
better than completely stopping the service. When paused, what state
would you
expect your app to be in?
Cheers,
Leif
Joost Jens wrote:
> Hello,
>
> I have started using the service and it does wonders for me.
>
> But my question is:
> How can I enable the pause and resume buttons for the service. Because
> they are both disabled when I have started the service.
>
> I hope you guys can help me.
>
> With kind regards,
> Joost Jens
|
|
From: Joost J. <jj...@fi...> - 2006-06-07 07:19:45
|
Hello, I have started using the service and it does wonders for me. But my question is: How can I enable the pause and resume buttons for the service. Because they are both disabled when I have started the service. I hope you guys can help me. With kind regards, Joost Jens |
|
From: David F. <dav...@zi...> - 2006-06-07 04:04:19
|
If I want the wrapper scripts to detect the proper architecture native libs to use, and I want to minimize the installation size of my software, can I have my installer script install just the OS bits for a given OS instead of the whole delta-pack? ie: For os.name="Linux", could I have my Installer just copy the Linux scripts plus the following files? lib/wrapper.jar lib/libwrapper-linux-ppc-64.so lib/libwrapper-linux-x86-32.so lib/libwrapper-linux-x86-64.so Thanks for clarifying, David > David, > > If you download the delta-pack distribution, all of the binaries > will be named in such a way > that the wrapper and scripts will be able to figure out which ones > need to be used. > > The platform specific distributions use the old naming format and > the binaries in them would > need to be renamed to make this feature work. > > Cheers, > Leif > >> Hi Leif: >> >> I'm not sure I follow the new changes in 3.2.x regarding arch. >> >> I use an installer called izPack and during installation, I >> install the wrapper.jar and the native library for the particular >> os.name and os.arch. I've been having a hard time finding out how >> I will know if I should install the 32 bit version or the 64 bit >> version of the windows native library and same for solaris. In >> this subject titled thread in the forum it seems like you say that >> JWS will "just figure out" the proper one to use. Is that true? >> Should I just install both the 32bit and 64 bit native libraries >> and JWS will sort out which one to use? >> >> Please advise. >> >> Regards, >> David |
|
From: Chandra P. <cp...@ig...> - 2006-06-06 22:04:38
|
This is great. But there is slight problem with simply using -Xdebug alone. There are two ways of debugging JVMs. JVMPI and JVMTI. You can run VM with -Xdebug alone but it's not really interesting. However, I think that's ok for the detecting JVMPI since JVMPI uses -Xdebug option. http://blogs.sun.com/roller/page/kto?entry=using_vm_agents As far as I have tested, under JVMTI you can simply use -agentlib:jdwp option to debug. -Xdebug is not necessary. For -Xdebug http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html For JVMTI and JVMPI with debugging (JPDA) http://java.sun.com/j2se/1.5.0/docs/guide/jpda/enhancements.html Leif Mortenson wrote: > Chandra, David, > I made some changes for the 3.2.1 release. > > The wrapper will now enter a "DebugJVM" mode if the > wrapper.java.command ends > in "jdb" or "jdb.exe", or the "-Xdebug" argument is passed to the JVM. > > When operating in the "DebugJVM" mode, a warning will be displayed on > JVM launch > if any of the timeouts are not set to 0. The warning warns that the > ability to detect and > restart a frozen JVM will be disabled. > > Then if a timeout does occur, it will be ignored. But the first such > timeout will cause > another warning to be displayed to the user stating which timeout was > encountered and > saying that it may be caused by a debugger having suspended the JVM. > > Does this make everyone happy? > > Cheers, > Leif > > > Chandra Patni wrote: > >> I see how your proposal is more compliant and semantically correct >> than mine which is in the spirit of 'benevolent dictatorship'. Either >> way, it would be nice to have nice debugging experience. >> >> >> >> da...@sm... wrote: >> >>> I agree and disagree. I don't think the wrapper should set its ping >>> to 0 if debug is set, but I do think it should not restart when >>> debug is set. Maybe record in in the log file that it timed out, but >>> due to debug existing, the application won't be restarted, unless >>> there is some super-sexy way of finding out from the debugged >>> application that the wrapper thread (and others depending upon the >>> debugger that connects to it) has been debug paused. >>> >>> My thoughts at least! >>> >>> Cheers again Leif! >>> >>> Quoting Chandra Patni <cp...@ig...>: >>> >>>> I think wrapper should set ping timeout to zero if -Xdebug and >>>> -Xrunjdwp .... option is set for JVMDI supporting VMs. And print out >>>> this as warning. It should also do the same when -agentlib:jdwp... >>>> option is set for newer JVMTI supporting VMs. Otherwise, it will always >>>> result in surprised user. >>>> >>>> >>>> >>>> Leif Mortenson wrote: >>>> >>>>> Chandra, >>>>> I'm not sure of any way to let the Wrapper know that the JVM is >>>>> paused due to >>>>> debug mode. You would not want to disable the ping timeout simply >>>>> because >>>>> debug was enabled. I should add a note about this or maybe >>>>> make the Wrapper >>>>> provide some additional info if the command line contains -Xdebug. >>>>> Setting >>>>> wrapper.ping.timeout to 0 should solve the problem for you however. >>>>> >>>>> Cheers, >>>>> Leif >>>>> >>>>> Chandra Patni wrote: >>>>> >>>>>> I started my JVM with >>>>>> -Xdebug -Xnoagent -Djava.compiler=NONE >>>>>> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 >>>>>> >>>>>> and attached IDE debugger. Blocked a JSP thread on a breakpoint. >>>>>> The wrapper restarts/shuts down (depending on >>>>>> wrapper.disable_restarts=TRUE) the VM. >>>>>> >>>>>> >>>>>> ERROR | wrapper | 2006/05/09 16:35:02 | JVM appears hung: >>>>>> Timed out waiting for signal from JVM. >>>>>> ERROR | wrapper | 2006/05/09 16:35:02 | JVM did not exit on >>>>>> request, terminated >>>>>> STATUS | wrapper | 2006/05/09 16:35:03 | JVM Restarts disabled. >>>>>> Shutting down. >>>>>> STATUS | wrapper | 2006/05/09 16:35:03 | <-- Wrapper Stopped >>>>>> >>>>>> I can set the wrapper.ping.timeout to zero to avoid this. >>>>>> Shouldn't wrapper should detect debug mode? >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> Using Tomcat but need to do more? Need to support web services, >>>>>> security? >>>>>> Get stuff done quickly with pre-integrated technology to make >>>>>> your job easier >>>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>>>> Geronimo >>>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>>>>> >>>>>> _______________________________________________ >>>>>> Wrapper-user mailing list >>>>>> Wra...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> Using Tomcat but need to do more? Need to support web services, >>>>> security? >>>>> Get stuff done quickly with pre-integrated technology to make >>>>> your job easier >>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>>> Geronimo >>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>>>> >>>>> _______________________________________________ >>>>> Wrapper-user mailing list >>>>> Wra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> Using Tomcat but need to do more? Need to support web services, >>>> security? >>>> Get stuff done quickly with pre-integrated technology to make your >>>> job easier >>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>> Geronimo >>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>>> >>>> _______________________________________________ >>>> Wrapper-user mailing list >>>> Wra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> Using Tomcat but need to do more? Need to support web services, >>> security? >>> Get stuff done quickly with pre-integrated technology to make your >>> job easier >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>> Geronimo >>> http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642 >>> _______________________________________________ >>> Wrapper-user mailing list >>> Wra...@li... >>> https://lists.sourceforge.net/lists/listinfo/wrapper-user >> >> >> >> ------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job >> easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Wrapper-user mailing list >> Wra...@li... >> https://lists.sourceforge.net/lists/listinfo/wrapper-user >> > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Bill R. <ws...@gm...> - 2006-05-31 12:18:37
|
Leif, It was the permissions. I opened them up and it is working fine. I had contructed my application directory by hand with my user account. thanks, Bill On 5/30/06, Leif Mortenson <le...@ta...> wrote: > > Jonathan, > See my comments in line below. Esp. at the end. > > jonathan loday wrote: > > I'm trying to lauch my java application at the startup of a debian. For > the moment my app is only a loading an icone, in the system tray. > > It is working properly and I can start and stop it using ./mywrapper > start and ./mywrapper stop. > > I merely followed the instructions here : > http://wrapper.tanukisoftware.org/doc/english/launch-nix-boot-debian.html > > Creating the symbolic link in /etc/init.d > > ln -s /usr/lib/myapp/bin/myapp /etc/init.d/myapp > > The link is working. > > Then configuring the rc*.d > > update-rc.d myapp start 99 5 . stop 99 0 1 6 . > > This also working because as you can see below the wrapper is called and > runned. > > However, it has a problem running the JVM. I even set the JAVA_HOME in > the conf file but it's not working. > > > > If someone could help me, it would be great, thanks. > > > > This is my config file : > > > > # Java Application > > set.default.JAVA_HOME=/usr/lib/j2sdk1.5-sun > > > The set.default.JAVA_HOME property works by looking to see if the > JAVA_HOME > environment variable is already set. If it is, it does nothing. If > not, then it will > set the variable to the value specified. > > set.JAVA_HOME=/usr/lib/j2sdk1.5-sun > > > The set.JAVA_HOME property will always set the JAVA_HOME environment > variable to the specified value regardless of whether or not the > variable was > already set. > > export JAVA_HOME > > > This is ignored by the wrapper as it is an invalid property. > > In the case above, the JAVA_HOME variable will always be set to > "usr/lib/j2sdk1.5-sun" > > wrapper.java.command=%JAVA_HOME%/bin/java > > > > # Java Main class. This class must implement the WrapperListener > interface > > # or guarantee that the WrapperManager class is initialized. Helper > > # classes are provided to do this for you. See the Integration section > > # of the documentation for details. > > wrapper.java.mainclass=Main > > > > # Java Classpath (include wrapper.jar) Add class path elements as > > # needed starting from 1 > > wrapper.java.classpath.1=TestTray.jar > > wrapper.java.classpath.2=../lib/wrapper.jar > > wrapper.java.classpath.3=jdic.jar > > > > # Java Library Path (location of Wrapper.DLL or libwrapper.so) > > wrapper.java.library.path.1=../lib > > #wrapper.java.library.path.2=lib/libwrapper-linux-x86-32.so > > # Java Additional Parameters > > #wrapper.java.additional.1= > > > > > > This is the wrapper.log after the startup > > > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[0] : > /usr/lib/j2sdk1.5-sun/bin/java > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[1] : - > Djava.library.path=../lib > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[2] : -classpath > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[3] : > TestTray.jar:../lib/wrapper.jar:jdic.jar > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[4] : - > Dwrapper.key=SyGk9qLsm4ALr7Bs > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[5] : - > Dwrapper.port=32000 > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[6] : - > Dwrapper.jvm.port.min=31000 > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[7] : - > Dwrapper.jvm.port.max=31999 > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[8] : - > Dwrapper.debug=TRUE > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[9] : - > Dwrapper.pid=3005 > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[10] : - > Dwrapper.version=3.2.0 > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[11] : - > Dwrapper.native_library=wrapper > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[12] : - > Dwrapper.service=TRUE > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[13] : - > Dwrapper.cpu.timeout=10 > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[14] : - > Dwrapper.jvmid=4 > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[15] : Main > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[16] : --id > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[17] : 51 > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[18] : --address > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[19] : bachibouzouk > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[20] : --home > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[21] : ./ > > DEBUG | wrapper | 2006/05/25 17:27:58 | Command[22] : netmon-conf.xml > > STATUS | wrapper | 2006/05/25 17:27:58 | Launching a JVM... > > INFO | jvm 4 | 2006/05/25 17:27:58 | WrapperManager class > initialized by thread: main Using classloader: > sun.misc.Launcher$AppClassLoader@198dfaf > > INFO | jvm 4 | 2006/05/25 17:27:58 | Wrapper (Version 3.2.0) > http://wrapper.tanukisoftware.org > > INFO | jvm 4 | 2006/05/25 17:27:58 | > > INFO | jvm 4 | 2006/05/25 17:27:58 | Wrapper Manager: JVM #4 > > INFO | jvm 4 | 2006/05/25 17:27:58 | Running a 32-bit JVM. > > INFO | jvm 4 | 2006/05/25 17:27:58 | Wrapper Manager: Registering > shutdown hook > > INFO | jvm 4 | 2006/05/25 17:27:58 | Wrapper Manager: Using wrapper > > INFO | jvm 4 | 2006/05/25 17:27:58 | Load native library. One or > more attempts may fail if platform specific libraries do not exist. > > INFO | jvm 4 | 2006/05/25 17:27:58 | Loaded native library: > libwrapper-linux-x86-32.so > > INFO | jvm 4 | 2006/05/25 17:27:58 | Calling native initialization > method. > > INFO | jvm 4 | 2006/05/25 17:27:58 | Inside native WrapperManager > initialization method > > INFO | jvm 4 | 2006/05/25 17:27:58 | Java Version : 1.5.0_06-b05Java HotSpot(TM) Client VM > > INFO | jvm 4 | 2006/05/25 17:27:58 | Java VM Vendor : Sun > Microsystems Inc. > > INFO | jvm 4 | 2006/05/25 17:27:58 | > > INFO | jvm 4 | 2006/05/25 17:27:58 | WrapperManager.start( > Main@12a54f9, args["--id", "51", "--address", "bachibouzouk", "--home", > "./", "netmon-conf.xml"]) called by thread: main > > INFO | jvm 4 | 2006/05/25 17:27:58 | Open socket to > wrapper...Wrapper-Connection > > INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using > local port 31000 > > INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using > local port 31001 > > INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using > local port 31002 > > INFO | jvm 4 | 2006/05/25 17:27:58 | Opened Socket from 31003 to > 32000 > > INFO | jvm 4 | 2006/05/25 17:27:58 | Send a packet KEY : > SyGk9qLsm4ALr7Bs > > INFO | jvm 4 | 2006/05/25 17:27:58 | > handleSocket(Socket[addr=/127.0.0.1,port=32000,localport=31003]) > > DEBUG | wrapperp | 2006/05/25 17:27:58 | accepted a socket from > 127.0.0.1 on port 31003 > > DEBUG | wrapperp | 2006/05/25 17:27:58 | read a packet KEY : > SyGk9qLsm4ALr7Bs > > DEBUG | wrapper | 2006/05/25 17:27:58 | Got key from JVM: > SyGk9qLsm4ALr7Bs > > DEBUG | wrapperp | 2006/05/25 17:27:58 | send a packet LOW_LOG_LEVEL : > 1 > > DEBUG | wrapperp | 2006/05/25 17:27:58 | send a packet PING_TIMEOUT : > 30 > > DEBUG | wrapperp | 2006/05/25 17:27:58 | send a packet PROPERTIES : > (Property Values) > > DEBUG | wrapper | 2006/05/25 17:27:58 | Start Application. > > DEBUG | wrapperp | 2006/05/25 17:27:58 | send a packet START : start > > INFO | jvm 4 | 2006/05/25 17:27:59 | Received a packet > LOW_LOG_LEVEL : 1 > > INFO | jvm 4 | 2006/05/25 17:27:59 | Wrapper Manager: LowLogLevel > from Wrapper is 1 > > INFO | jvm 4 | 2006/05/25 17:27:59 | Received a packet PING_TIMEOUT > : 30 > > INFO | jvm 4 | 2006/05/25 17:27:59 | Wrapper Manager: PingTimeout > from Wrapper is 30000 > > INFO | jvm 4 | 2006/05/25 17:27:59 | Received a packet PROPERTIES : > (Property Values) > > INFO | jvm 4 | 2006/05/25 17:27:59 | Monitoring of the JVM thread > count will be delayed for 1 seconds. > > INFO | jvm 4 | 2006/05/25 17:27:59 | Received a packet START : > start > > INFO | jvm 4 | 2006/05/25 17:27:59 | calling listener.start() > > INFO | jvm 4 | 2006/05/25 17:27:59 | start > > DEBUG | wrapper | 2006/05/25 17:27:59 | Signal trapped. Details: > > DEBUG | wrapper | 2006/05/25 17:27:59 | signal number=17 (SIGCHLD), > source="unknown" > > DEBUG | wrapper | 2006/05/25 17:27:59 | Received SIGCHLD, calling > wait(). > > DEBUG | wrapper | 2006/05/25 17:27:59 | wait() returned, child process > should be gone. > > DEBUG | wrapperp | 2006/05/25 17:27:59 | socket read no code (closed?). > > DEBUG | wrapper | 2006/05/25 17:27:59 | JVM process is gone. > > ERROR | wrapper | 2006/05/25 17:27:59 | JVM exited while starting the > application. > > DEBUG | wrapperp | 2006/05/25 17:27:59 | server listening on port > 32000. > > DEBUG | wrapper | 2006/05/25 17:27:59 | JVM was only running for 0 > seconds leading to a failed restart count of 4 > > > This log is peculiar. You have only posted the log from the 4th > attempted > start of the JVM. Do the first 3 attempts look exactly the same? I > wonder > because of the following: > > INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using > local port 31000 > INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using > local port 31001 > INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using > local port 31002 > INFO | jvm 4 | 2006/05/25 17:27:58 | Opened Socket from 31003 to > 32000 > > Most likely jvm 1 used port 31000, jvm 2 used port 31001, > and jvm 3 used port 31002. It is odd that they are still bound. > This would happen on Solaris, but not usually the case on Debian. > Are those JVM processes still hanging around somehow? > > From your log, the Wrapper appears to be working correctly. The > Wrapper starts up and launched the JVM process. It launches > normally and is running for a second or two. But then suddenly > dies as if killed by a -9 signal. > > Can you confirm that the JVM processes are indeed gone? > Try setting the following in the wrapper.conf or the JVM processes > will most likely exit on their own after around 30 seconds if they > have simply been detached some how. > wrapper.startup.timeout=600 > wrapper.ping.timeout=600 > > Cheers, > Leif > > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Bill R. <bi...@bi...> - 2006-05-31 12:13:47
|
Leif, It was the permission settings on the files in that directory. I had manually constructed it with my user account. I opened up the permissions and now it is working! thanks, Bill On 5/30/06, Leif Mortenson <le...@ta...> wrote: > > Bill, > One more question. In your log from running as a service. There were > a couple places > where the line feeds were missing. There used to be an old bug that > looked a little like > this that was being caused by synchronization problems. I have never > seen it since it > was fixed. But I wanted to confirm whether or not you are seeing these > missing line > feeds in your original unmodified log file or whether this is just an > artifact of the email? > > DEBUG | wrapper | 2006/05/30 11:32:16 | Service command: "C:\Program > > Files\VCS Server\wrapper.exe" -s wrapper.conf > > STATUS | wrapper | 2006/05/30 11:32:17 | VCS installed. > > STATUS | wrapper | 2006/05/30 11:32:23 | --> Wrapper Started as Service > > DEBUG | wrapper | 2006/05/30 11:32:23 | Using tick timer. > > DEBUG | wrapperp | 2006/05/30 11:32:23 | server listening on port > 32000. > > DEBUG | wrapper | 2006/05/30 11:32:23 | Classpath element, > > wrapper.java.classpath.2 , does not exist: C:\Program Files\VCS > > Server\wrappertesta.jar > > STATUS | wrapper | 2006/05/30 11:32:23 | Launching a JVM... > > DEBUG | wrapper | 2006/05/30 11:32:23 | command: > > "C:\WINDOWS\system32\java.exe" - Duser.timezone=UTC > > -Duser.dir="C:\Program Files\VCS Server" -Xms128m -Xmx256m > > -Djava.library.path="C:\Program Files\VCS Server\vcsNative" -classpath > > "C:\Program Files\VCS Server\wrapper.jar;C:\Program Files\VCS > > Server\wrappertesta.jar;C:\Program Files\VCS Server\ImageServer.jar" - > > Dwrapper.key="xEe2o3phm7_2ayOo" -Dwrapper.port=32000 > > -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 > > -Dwrapper.debug="TRUE" -Dwrapper.pid=640 -Dwrapper.version="3.2.0" > > -Dwrapper.native_library= "wrapper" -Dwrapper.service="TRUE" > > -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 > > org.tanukisoftware.wrapper.WrapperSimpleApp ImageServerDEBUG | > > wrapper | 2006/05/30 11:32:23 | JVM started (PID=3952) > > INFO | jvm 1 | 2006/05/30 11:32:23 | > > java.lang.NoClassDefFoundError: > > org/tanukisoftware/wrapper/WrapperSimpleAppINFO | jvm 1 | > > 2006/05/30 11:32:23 | Exception in thread "main" > There are two examples of this above > > 1) "... ImageServerDEBUG ..." > Should be: > "... ImageServer > DEBUG ..." > > 2) "...WrapperSimpleAppINFO..." > Shoulb be: > "...WrapperSimpleApp > INFO..." > > If you are seeing the missing line feeds. Are they happening reliably > in the same place > every time you run the wrapper or are they happening at random locations. > > I noticed that they do not appear in the log file from when you run as a > console app. > > Cheers, > Leif > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Leif M. <le...@ta...> - 2006-05-31 02:02:19
|
Jonathan,
See my comments in line below. Esp. at the end.
jonathan loday wrote:
> I'm trying to lauch my java application at the startup of a debian. For the moment my app is only a loading an icone, in the system tray.
> It is working properly and I can start and stop it using ./mywrapper start and ./mywrapper stop.
> I merely followed the instructions here : http://wrapper.tanukisoftware.org/doc/english/launch-nix-boot-debian.html
> Creating the symbolic link in /etc/init.d
> ln -s /usr/lib/myapp/bin/myapp /etc/init.d/myapp
> The link is working.
> Then configuring the rc*.d
> update-rc.d myapp start 99 5 . stop 99 0 1 6 .
> This also working because as you can see below the wrapper is called and runned.
> However, it has a problem running the JVM. I even set the JAVA_HOME in the conf file but it's not working.
>
> If someone could help me, it would be great, thanks.
>
> This is my config file :
>
> # Java Application
> set.default.JAVA_HOME=/usr/lib/j2sdk1.5-sun
>
The set.default.JAVA_HOME property works by looking to see if the JAVA_HOME
environment variable is already set. If it is, it does nothing. If
not, then it will
set the variable to the value specified.
> set.JAVA_HOME=/usr/lib/j2sdk1.5-sun
>
The set.JAVA_HOME property will always set the JAVA_HOME environment
variable to the specified value regardless of whether or not the
variable was
already set.
> export JAVA_HOME
>
This is ignored by the wrapper as it is an invalid property.
In the case above, the JAVA_HOME variable will always be set to
"usr/lib/j2sdk1.5-sun"
> wrapper.java.command=%JAVA_HOME%/bin/java
>
> # Java Main class. This class must implement the WrapperListener interface
> # or guarantee that the WrapperManager class is initialized. Helper
> # classes are provided to do this for you. See the Integration section
> # of the documentation for details.
> wrapper.java.mainclass=Main
>
> # Java Classpath (include wrapper.jar) Add class path elements as
> # needed starting from 1
> wrapper.java.classpath.1=TestTray.jar
> wrapper.java.classpath.2=../lib/wrapper.jar
> wrapper.java.classpath.3=jdic.jar
>
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> wrapper.java.library.path.1=../lib
> #wrapper.java.library.path.2=lib/libwrapper-linux-x86-32.so
> # Java Additional Parameters
> #wrapper.java.additional.1=
>
>
> This is the wrapper.log after the startup
>
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[0] : /usr/lib/j2sdk1.5-sun/bin/java
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[1] : -Djava.library.path=../lib
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[2] : -classpath
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[3] : TestTray.jar:../lib/wrapper.jar:jdic.jar
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[4] : -Dwrapper.key=SyGk9qLsm4ALr7Bs
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[5] : -Dwrapper.port=32000
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[6] : -Dwrapper.jvm.port.min=31000
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[7] : -Dwrapper.jvm.port.max=31999
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[8] : -Dwrapper.debug=TRUE
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[9] : -Dwrapper.pid=3005
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[10] : -Dwrapper.version=3.2.0
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[11] : -Dwrapper.native_library=wrapper
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[12] : -Dwrapper.service=TRUE
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[13] : -Dwrapper.cpu.timeout=10
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[14] : -Dwrapper.jvmid=4
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[15] : Main
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[16] : --id
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[17] : 51
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[18] : --address
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[19] : bachibouzouk
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[20] : --home
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[21] : ./
> DEBUG | wrapper | 2006/05/25 17:27:58 | Command[22] : netmon-conf.xml
> STATUS | wrapper | 2006/05/25 17:27:58 | Launching a JVM...
> INFO | jvm 4 | 2006/05/25 17:27:58 | WrapperManager class initialized by thread: main Using classloader: sun.misc.Launcher$AppClassLoader@198dfaf
> INFO | jvm 4 | 2006/05/25 17:27:58 | Wrapper (Version 3.2.0) http://wrapper.tanukisoftware.org
> INFO | jvm 4 | 2006/05/25 17:27:58 |
> INFO | jvm 4 | 2006/05/25 17:27:58 | Wrapper Manager: JVM #4
> INFO | jvm 4 | 2006/05/25 17:27:58 | Running a 32-bit JVM.
> INFO | jvm 4 | 2006/05/25 17:27:58 | Wrapper Manager: Registering shutdown hook
> INFO | jvm 4 | 2006/05/25 17:27:58 | Wrapper Manager: Using wrapper
> INFO | jvm 4 | 2006/05/25 17:27:58 | Load native library. One or more attempts may fail if platform specific libraries do not exist.
> INFO | jvm 4 | 2006/05/25 17:27:58 | Loaded native library: libwrapper-linux-x86-32.so
> INFO | jvm 4 | 2006/05/25 17:27:58 | Calling native initialization method.
> INFO | jvm 4 | 2006/05/25 17:27:58 | Inside native WrapperManager initialization method
> INFO | jvm 4 | 2006/05/25 17:27:58 | Java Version : 1.5.0_06-b05 Java HotSpot(TM) Client VM
> INFO | jvm 4 | 2006/05/25 17:27:58 | Java VM Vendor : Sun Microsystems Inc.
> INFO | jvm 4 | 2006/05/25 17:27:58 |
> INFO | jvm 4 | 2006/05/25 17:27:58 | WrapperManager.start(Main@12a54f9, args["--id", "51", "--address", "bachibouzouk", "--home", "./", "netmon-conf.xml"]) called by thread: main
> INFO | jvm 4 | 2006/05/25 17:27:58 | Open socket to wrapper...Wrapper-Connection
> INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using local port 31000
> INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using local port 31001
> INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using local port 31002
> INFO | jvm 4 | 2006/05/25 17:27:58 | Opened Socket from 31003 to 32000
> INFO | jvm 4 | 2006/05/25 17:27:58 | Send a packet KEY : SyGk9qLsm4ALr7Bs
> INFO | jvm 4 | 2006/05/25 17:27:58 | handleSocket(Socket[addr=/127.0.0.1,port=32000,localport=31003])
> DEBUG | wrapperp | 2006/05/25 17:27:58 | accepted a socket from 127.0.0.1 on port 31003
> DEBUG | wrapperp | 2006/05/25 17:27:58 | read a packet KEY : SyGk9qLsm4ALr7Bs
> DEBUG | wrapper | 2006/05/25 17:27:58 | Got key from JVM: SyGk9qLsm4ALr7Bs
> DEBUG | wrapperp | 2006/05/25 17:27:58 | send a packet LOW_LOG_LEVEL : 1
> DEBUG | wrapperp | 2006/05/25 17:27:58 | send a packet PING_TIMEOUT : 30
> DEBUG | wrapperp | 2006/05/25 17:27:58 | send a packet PROPERTIES : (Property Values)
> DEBUG | wrapper | 2006/05/25 17:27:58 | Start Application.
> DEBUG | wrapperp | 2006/05/25 17:27:58 | send a packet START : start
> INFO | jvm 4 | 2006/05/25 17:27:59 | Received a packet LOW_LOG_LEVEL : 1
> INFO | jvm 4 | 2006/05/25 17:27:59 | Wrapper Manager: LowLogLevel from Wrapper is 1
> INFO | jvm 4 | 2006/05/25 17:27:59 | Received a packet PING_TIMEOUT : 30
> INFO | jvm 4 | 2006/05/25 17:27:59 | Wrapper Manager: PingTimeout from Wrapper is 30000
> INFO | jvm 4 | 2006/05/25 17:27:59 | Received a packet PROPERTIES : (Property Values)
> INFO | jvm 4 | 2006/05/25 17:27:59 | Monitoring of the JVM thread count will be delayed for 1 seconds.
> INFO | jvm 4 | 2006/05/25 17:27:59 | Received a packet START : start
> INFO | jvm 4 | 2006/05/25 17:27:59 | calling listener.start()
> INFO | jvm 4 | 2006/05/25 17:27:59 | start
> DEBUG | wrapper | 2006/05/25 17:27:59 | Signal trapped. Details:
> DEBUG | wrapper | 2006/05/25 17:27:59 | signal number=17 (SIGCHLD), source="unknown"
> DEBUG | wrapper | 2006/05/25 17:27:59 | Received SIGCHLD, calling wait().
> DEBUG | wrapper | 2006/05/25 17:27:59 | wait() returned, child process should be gone.
> DEBUG | wrapperp | 2006/05/25 17:27:59 | socket read no code (closed?).
> DEBUG | wrapper | 2006/05/25 17:27:59 | JVM process is gone.
> ERROR | wrapper | 2006/05/25 17:27:59 | JVM exited while starting the application.
> DEBUG | wrapperp | 2006/05/25 17:27:59 | server listening on port 32000.
> DEBUG | wrapper | 2006/05/25 17:27:59 | JVM was only running for 0 seconds leading to a failed restart count of 4
>
This log is peculiar. You have only posted the log from the 4th attempted
start of the JVM. Do the first 3 attempts look exactly the same? I wonder
because of the following:
INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using local port 31000
INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using local port 31001
INFO | jvm 4 | 2006/05/25 17:27:58 | Failed attempt to bind using local port 31002
INFO | jvm 4 | 2006/05/25 17:27:58 | Opened Socket from 31003 to 32000
Most likely jvm 1 used port 31000, jvm 2 used port 31001,
and jvm 3 used port 31002. It is odd that they are still bound.
This would happen on Solaris, but not usually the case on Debian.
Are those JVM processes still hanging around somehow?
From your log, the Wrapper appears to be working correctly. The
Wrapper starts up and launched the JVM process. It launches
normally and is running for a second or two. But then suddenly
dies as if killed by a -9 signal.
Can you confirm that the JVM processes are indeed gone?
Try setting the following in the wrapper.conf or the JVM processes
will most likely exit on their own after around 30 seconds if they
have simply been detached some how.
wrapper.startup.timeout=600
wrapper.ping.timeout=600
Cheers,
Leif
|