Menu
▾
▴
wrapper-user — User issues for Wrapper. (Support questions, etc.)
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: Leif M. <lei...@ta...> - 2009-02-20 18:28:44
|
Salman, You are running wrapper-windows-x86-32.exe, that is then launching a 64-bit version of Java. The JVM loads the org.tanukisoftware.wrapper.WrapperManager class which in turn attempts to load the wrapper-windows-x86-64.dll The problem you are having is that the copy of Java you are running is 64-bit. Cheers, Leif On Sat, Feb 21, 2009 at 2:59 AM, JAN Salman <Sal...@al...> wrote: > Hi Leif, > As I understand that it is the wrapper-windows-x86-32.exe that should > load to wrapper-windows-x86-32.dll before even the JVM is invoked. > > The error we are getting is that the wrapper-windows-x86-32.exe is not > loading wrapper-windows-x86-32.dll (instead looking for > wrapper-windows-x86-64.exe). I do not understand why that error/warning > message would be related to JVM being a 32bit version. > > Many be that, I am not understanding the sequence as to what call what. > > I understand wrapper-windows-x86-32.exe---call--> > wrapper-windows-x86-32.dll---calls---> wrapper.jar > (JVM)---invokes-->Java code/class > > Can u explain? > > Thanks > Salman > > > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: Friday, February 20, 2009 11:31 AM > To: JAN Salman > Cc: wra...@li...; SUNKAVELLI Sai; BASNYAT > Dharmendra > Subject: Re: [Wrapper-user] wrapper service going down with > thefollowingexceptions > > Salman, > Yes, you are using a 32-bit version of the Wrapper, but you are using > that to launch a 64-bit version of Java. That part is fine, but a > 64-bit wrapper.dll is required to work with the 64-bit version of > Java. > The Java version is displayed here from your log: > --- > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: > Running a 64-bit JVM. > ... > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: Java > Version : 1.5.0_16-b02 Java HotSpot(TM) 64-Bit Server VM > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: Java > VM Vendor : Sun Microsystems Inc. > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: OS > Name : Windows 2003 > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: OS > Arch : amd64 > --- > > Unless you need the 64-bit JVM, please try installing a 32-bit version > of Java. That should fix your problem. > > Cheers, > Leif > > On Sat, Feb 21, 2009 at 1:10 AM, JAN Salman > <Sal...@al...> wrote: >> Hi Leif, >> The Windows Service executable path is : >> >> "C:\Program Files >> (x86)\wrapper-delta-pack-3.3.1\bin\wrapper-windows-x86-32.exe" -s >> "C:\Program Files (x86)\wrapper-delta-pack-3.3.1\conf\wrapper.conf" >> >> You can see that we are using wrapper-windows-x86-32.exe >> >> -----Original Message----- >> From: JAN Salman >> Sent: Friday, February 20, 2009 11:07 AM >> To: 'Leif Mortenson'; wra...@li... >> Cc: SUNKAVELLI Sai; BASNYAT Dharmendra >> Subject: RE: [Wrapper-user] wrapper service going down with >> thefollowingexceptions >> >> Hi Leif, >> The issue appears to be that we are using the attached Wrapper Windows >> Service package (which is a 32 bit version). >> >> The Windows 2003 Server we have is a 64-bit OS and setup in >> compatibility mode. Meaning u can also run 32-bit apps on it. >> >> The issue is why the wrapper-windows-x86-32.dll is not loading >> wrapper-windows-x86-32.dll , and instead asking for >> wrapper-windows-x86-64.dll? >> >> Thanks >> Salman >> >> >> -----Original Message----- >> From: Leif Mortenson [mailto:lei...@ta...] >> Sent: Thursday, February 19, 2009 9:15 PM >> To: wra...@li... >> Cc: JAN Salman >> Subject: Re: [Wrapper-user] wrapper service going down with >> thefollowingexceptions >> >> Sai, >> As the log output states, the problem is that your wrapper.dll file is >> not being located correctly: >> >> --- >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: >> Unable to load native library: wrapper-windows-x86-64.dll Cause: no >> wrapper-windows-x86-64 in java.library.path >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: >> Unable to load native library: wrapper.dll Cause: no wrapper in >> java.library.path >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: WARNING - >> Unable to load the Wrapper's native library because none of the >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> following files: >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> wrapper-windows-x86-64.dll >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> wrapper.dll >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> could be located on the following java.library.path: >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> C:\Program Files\wrapper-delta-pack-3.3.1\lib >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> C:\Program Files\wrapper-delta-pack-3.3.1\lib\windows-x86-32 >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> Please see the documentation for the wrapper.java.library.path >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> configuration property. >> INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: >> System signals will not be handled correctly. >> --- >> >> Your java library path is currently: >> -Djava.library.path="C:/Program >> Files/wrapper-delta-pack-3.3.1/lib;C:/Program >> Files/wrapper-delta-pack-3.3.1/lib/windows-x86-32" >> >> Can you confirm that a wrapper.dll or wrapper-windows-x86-64.dll >> exists in that directory. I just noticed in your log file that you >> are running the community edition. We do not include 64-bit windows >> versions in the community edition at this time. To get this working, >> you will need to either use a 32-bit JVM or upgrade to a Standard >> edition server license. >> >> Sorry I had not noticed that in your first email. The malformed >> library path looked like the problem. >> >> Please let me know if you have any questions. >> >> Sincerely, >> Leif Mortenson, >> Tanuki Software, Ltd. >> >> >> On Fri, Feb 20, 2009 at 4:43 AM, Sunkavelli, Sai M (Sai)** CTR ** >> <sai...@al...> wrote: >>> >>> Hi Leif, >>> >>> I changed the path and removed the additional '\' in the path as you >>> suggested below and still we have the problem. Here is the log file >> with >>> the error, could you please let us know why this is happening. >>> >>> Thanks >>> -Sai >>> >>> >>> >>> -----Original Message----- >>> From: Leif Mortenson [mailto:lei...@ta...] >>> Sent: Saturday, February 14, 2009 10:44 AM >>> To: wra...@li... >>> Cc: Jan, Salman (Salman) >>> Subject: Re: [Wrapper-user] wrapper service going down with >>> thefollowingexceptions >>> >>> Sai, >>> The problem is that the Wrapper's native DLL is not being located >>> correctly. Without that, the wrapper loses the ability to protect > the >>> Java process from system logout events. This message should have >>> been visible in your logs even without enabling debug output: >>> >>> --- >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: WARNING - >>> Unable to load the Wrapper's native library because none of the >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> following files: >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> wrapper-windows-x86-64.dll >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> wrapper.dll >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> could be located on the following java.library.path: >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> C:\Program Files\wrapper-delta-pack-3.3.1\lib >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> Please see the documentation for the wrapper.java.library.path >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> configuration property. >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> System signals will not be handled correctly. >>> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >>> --- >>> >>> The generated library path is currently set to: >>> -Djava.library.path="C:/Program Files/wrapper-delta-pack-3.3.1\/lib" >>> >>> My guess is that the extra slash before the lib is what is causing >>> your problems. Try removing that by correcting the following in > your >>> wrapper.conf: >>> wrapper.java.library.path.1=C:/Program >>> Files/wrapper-delta-pack-3.3.1\/lib >>> Change to: >>> wrapper.java.library.path.1=C:/Program >>> Files/wrapper-delta-pack-3.3.1/lib >>> >>> Let me know how this works for you. >>> >>> Cheers, >>> Leif >>> >>> >>> >>> On Sat, Feb 14, 2009 at 8:47 AM, Sunkavelli, Sai M (Sai)** CTR ** >>> <sai...@al...> wrote: >>>> Hi Leif, >>>> >>>> Here are the log and conf files. Please let us know why this User >>>> logged out error is occurring. >>>> >>>> Thanks >>>> -Sai >>>> >>>> -----Original Message----- >>>> From: Leif Mortenson [mailto:lei...@ta...] >>>> Sent: Wednesday, February 11, 2009 10:54 PM >>>> To: wra...@li... >>>> Cc: Jan, Salman (Salman) >>>> Subject: Re: [Wrapper-user] wrapper service going down with the >>>> followingexceptions >>>> >>>> Salman, >>>> I am not able to tell exactly what is happening from what was sent. >>>> Could you please set the wrapper.debug=true property, delete any >>>> existing wrapper.log file, then reproduce this. Send me the >> resulting >>> >>>> wrapper.log and wrapper.conf files in entirety as attachments. I >>>> should then be able to tell you what is happening. >>>> >>>> Cheers, >>>> Leif >>>> >>>> On Thu, Feb 12, 2009 at 8:09 AM, Sunkavelli, Sai M (Sai)** CTR ** >>>> <sai...@al...> wrote: >>>>> Hi >>>>> >>>>> Please help with the following exception in the wrapper log and my >>>>> java program is terminating after this error. >>>>> >>>>> >>>>> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. > Ignored. >>>>> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. > Ignored. >>>>> STATUS | wrapper | 2009/02/11 16:43:16 | <-- Wrapper Stopped >>>>> >>>>> Thanks and regards >>>>> Sai Manohar Sunkavelli. |
|
From: Leif M. <lei...@ta...> - 2009-02-20 16:31:29
|
Salman, Yes, you are using a 32-bit version of the Wrapper, but you are using that to launch a 64-bit version of Java. That part is fine, but a 64-bit wrapper.dll is required to work with the 64-bit version of Java. The Java version is displayed here from your log: --- INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: Running a 64-bit JVM. ... INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: Java Version : 1.5.0_16-b02 Java HotSpot(TM) 64-Bit Server VM INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: Java VM Vendor : Sun Microsystems Inc. INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: OS Name : Windows 2003 INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: OS Arch : amd64 --- Unless you need the 64-bit JVM, please try installing a 32-bit version of Java. That should fix your problem. Cheers, Leif On Sat, Feb 21, 2009 at 1:10 AM, JAN Salman <Sal...@al...> wrote: > Hi Leif, > The Windows Service executable path is : > > "C:\Program Files > (x86)\wrapper-delta-pack-3.3.1\bin\wrapper-windows-x86-32.exe" -s > "C:\Program Files (x86)\wrapper-delta-pack-3.3.1\conf\wrapper.conf" > > You can see that we are using wrapper-windows-x86-32.exe > > -----Original Message----- > From: JAN Salman > Sent: Friday, February 20, 2009 11:07 AM > To: 'Leif Mortenson'; wra...@li... > Cc: SUNKAVELLI Sai; BASNYAT Dharmendra > Subject: RE: [Wrapper-user] wrapper service going down with > thefollowingexceptions > > Hi Leif, > The issue appears to be that we are using the attached Wrapper Windows > Service package (which is a 32 bit version). > > The Windows 2003 Server we have is a 64-bit OS and setup in > compatibility mode. Meaning u can also run 32-bit apps on it. > > The issue is why the wrapper-windows-x86-32.dll is not loading > wrapper-windows-x86-32.dll , and instead asking for > wrapper-windows-x86-64.dll? > > Thanks > Salman > > > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: Thursday, February 19, 2009 9:15 PM > To: wra...@li... > Cc: JAN Salman > Subject: Re: [Wrapper-user] wrapper service going down with > thefollowingexceptions > > Sai, > As the log output states, the problem is that your wrapper.dll file is > not being located correctly: > > --- > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: > Unable to load native library: wrapper-windows-x86-64.dll Cause: no > wrapper-windows-x86-64 in java.library.path > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: > Unable to load native library: wrapper.dll Cause: no wrapper in > java.library.path > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: WARNING - > Unable to load the Wrapper's native library because none of the > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > following files: > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > wrapper-windows-x86-64.dll > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > wrapper.dll > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > could be located on the following java.library.path: > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > C:\Program Files\wrapper-delta-pack-3.3.1\lib > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > C:\Program Files\wrapper-delta-pack-3.3.1\lib\windows-x86-32 > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > Please see the documentation for the wrapper.java.library.path > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > configuration property. > INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: > System signals will not be handled correctly. > --- > > Your java library path is currently: > -Djava.library.path="C:/Program > Files/wrapper-delta-pack-3.3.1/lib;C:/Program > Files/wrapper-delta-pack-3.3.1/lib/windows-x86-32" > > Can you confirm that a wrapper.dll or wrapper-windows-x86-64.dll > exists in that directory. I just noticed in your log file that you > are running the community edition. We do not include 64-bit windows > versions in the community edition at this time. To get this working, > you will need to either use a 32-bit JVM or upgrade to a Standard > edition server license. > > Sorry I had not noticed that in your first email. The malformed > library path looked like the problem. > > Please let me know if you have any questions. > > Sincerely, > Leif Mortenson, > Tanuki Software, Ltd. > > > On Fri, Feb 20, 2009 at 4:43 AM, Sunkavelli, Sai M (Sai)** CTR ** > <sai...@al...> wrote: >> >> Hi Leif, >> >> I changed the path and removed the additional '\' in the path as you >> suggested below and still we have the problem. Here is the log file > with >> the error, could you please let us know why this is happening. >> >> Thanks >> -Sai >> >> >> >> -----Original Message----- >> From: Leif Mortenson [mailto:lei...@ta...] >> Sent: Saturday, February 14, 2009 10:44 AM >> To: wra...@li... >> Cc: Jan, Salman (Salman) >> Subject: Re: [Wrapper-user] wrapper service going down with >> thefollowingexceptions >> >> Sai, >> The problem is that the Wrapper's native DLL is not being located >> correctly. Without that, the wrapper loses the ability to protect the >> Java process from system logout events. This message should have >> been visible in your logs even without enabling debug output: >> >> --- >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: WARNING - >> Unable to load the Wrapper's native library because none of the >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> following files: >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> wrapper-windows-x86-64.dll >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> wrapper.dll >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> could be located on the following java.library.path: >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> C:\Program Files\wrapper-delta-pack-3.3.1\lib >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> Please see the documentation for the wrapper.java.library.path >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> configuration property. >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> System signals will not be handled correctly. >> INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: >> --- >> >> The generated library path is currently set to: >> -Djava.library.path="C:/Program Files/wrapper-delta-pack-3.3.1\/lib" >> >> My guess is that the extra slash before the lib is what is causing >> your problems. Try removing that by correcting the following in your >> wrapper.conf: >> wrapper.java.library.path.1=C:/Program >> Files/wrapper-delta-pack-3.3.1\/lib >> Change to: >> wrapper.java.library.path.1=C:/Program >> Files/wrapper-delta-pack-3.3.1/lib >> >> Let me know how this works for you. >> >> Cheers, >> Leif >> >> >> >> On Sat, Feb 14, 2009 at 8:47 AM, Sunkavelli, Sai M (Sai)** CTR ** >> <sai...@al...> wrote: >>> Hi Leif, >>> >>> Here are the log and conf files. Please let us know why this User >>> logged out error is occurring. >>> >>> Thanks >>> -Sai >>> >>> -----Original Message----- >>> From: Leif Mortenson [mailto:lei...@ta...] >>> Sent: Wednesday, February 11, 2009 10:54 PM >>> To: wra...@li... >>> Cc: Jan, Salman (Salman) >>> Subject: Re: [Wrapper-user] wrapper service going down with the >>> followingexceptions >>> >>> Salman, >>> I am not able to tell exactly what is happening from what was sent. >>> Could you please set the wrapper.debug=true property, delete any >>> existing wrapper.log file, then reproduce this. Send me the > resulting >> >>> wrapper.log and wrapper.conf files in entirety as attachments. I >>> should then be able to tell you what is happening. >>> >>> Cheers, >>> Leif >>> >>> On Thu, Feb 12, 2009 at 8:09 AM, Sunkavelli, Sai M (Sai)** CTR ** >>> <sai...@al...> wrote: >>>> Hi >>>> >>>> Please help with the following exception in the wrapper log and my >>>> java program is terminating after this error. >>>> >>>> >>>> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. >>>> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. >>>> STATUS | wrapper | 2009/02/11 16:43:16 | <-- Wrapper Stopped >>>> >>>> Thanks and regards >>>> Sai Manohar Sunkavelli. |
|
From: Leif M. <lei...@ta...> - 2009-02-20 04:38:14
|
Ilya, I like this idea and have added it to my todo list for a future release. There are memory leaks in the OS on most platforms when repeatedly setting environment variables so there are a few things that I have to restructure to make this work without those leaks. The values also need to be evaluated each time the JVM is restarted even when those values are stored in other property values. Thanks for the feedback. Cheers, Leif On Wed, Feb 11, 2009 at 3:36 PM, Ilya Volvovski <ivo...@cl...> wrote: > Hi, > > > > I would like to use names in wrapper configuration that would carry run time > information, such as timestamp, random number. The prime reason is to > generate various file names for each java invocation (I really need it for > gc.log). I could not find anything of the kind. What I suggest is having > predefined variables such as %TIMESTAMP%, %RANDOM% much like %WRAPPER_ARCH % > etc, but they are evaluated at java invocation time. > > > > Is it reasonable? Or something like that already exists? > > > > Thank you, > > Ilya Volvovski |
|
From: Leif M. <lei...@ta...> - 2009-02-20 02:37:21
|
Sai, As the log output states, the problem is that your wrapper.dll file is not being located correctly: --- INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: Unable to load native library: wrapper-windows-x86-64.dll Cause: no wrapper-windows-x86-64 in java.library.path INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager Debug: Unable to load native library: wrapper.dll Cause: no wrapper in java.library.path INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: WARNING - Unable to load the Wrapper's native library because none of the INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: following files: INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: wrapper-windows-x86-64.dll INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: wrapper.dll INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: could be located on the following java.library.path: INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: C:\Program Files\wrapper-delta-pack-3.3.1\lib INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: C:\Program Files\wrapper-delta-pack-3.3.1\lib\windows-x86-32 INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: Please see the documentation for the wrapper.java.library.path INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: configuration property. INFO | jvm 1 | 2009/02/17 19:11:28 | WrapperManager: System signals will not be handled correctly. --- Your java library path is currently: -Djava.library.path="C:/Program Files/wrapper-delta-pack-3.3.1/lib;C:/Program Files/wrapper-delta-pack-3.3.1/lib/windows-x86-32" Can you confirm that a wrapper.dll or wrapper-windows-x86-64.dll exists in that directory. I just noticed in your log file that you are running the community edition. We do not include 64-bit windows versions in the community edition at this time. To get this working, you will need to either use a 32-bit JVM or upgrade to a Standard edition server license. Sorry I had not noticed that in your first email. The malformed library path looked like the problem. Please let me know if you have any questions. Sincerely, Leif Mortenson, Tanuki Software, Ltd. On Fri, Feb 20, 2009 at 4:43 AM, Sunkavelli, Sai M (Sai)** CTR ** <sai...@al...> wrote: > > Hi Leif, > > I changed the path and removed the additional '\' in the path as you > suggested below and still we have the problem. Here is the log file with > the error, could you please let us know why this is happening. > > Thanks > -Sai > > > > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: Saturday, February 14, 2009 10:44 AM > To: wra...@li... > Cc: Jan, Salman (Salman) > Subject: Re: [Wrapper-user] wrapper service going down with > thefollowingexceptions > > Sai, > The problem is that the Wrapper's native DLL is not being located > correctly. Without that, the wrapper loses the ability to protect the > Java process from system logout events. This message should have > been visible in your logs even without enabling debug output: > > --- > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: WARNING - > Unable to load the Wrapper's native library because none of the > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > following files: > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > wrapper-windows-x86-64.dll > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > wrapper.dll > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > could be located on the following java.library.path: > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > C:\Program Files\wrapper-delta-pack-3.3.1\lib > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > Please see the documentation for the wrapper.java.library.path > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > configuration property. > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > System signals will not be handled correctly. > INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: > --- > > The generated library path is currently set to: > -Djava.library.path="C:/Program Files/wrapper-delta-pack-3.3.1\/lib" > > My guess is that the extra slash before the lib is what is causing > your problems. Try removing that by correcting the following in your > wrapper.conf: > wrapper.java.library.path.1=C:/Program > Files/wrapper-delta-pack-3.3.1\/lib > Change to: > wrapper.java.library.path.1=C:/Program > Files/wrapper-delta-pack-3.3.1/lib > > Let me know how this works for you. > > Cheers, > Leif > > > > On Sat, Feb 14, 2009 at 8:47 AM, Sunkavelli, Sai M (Sai)** CTR ** > <sai...@al...> wrote: >> Hi Leif, >> >> Here are the log and conf files. Please let us know why this User >> logged out error is occurring. >> >> Thanks >> -Sai >> >> -----Original Message----- >> From: Leif Mortenson [mailto:lei...@ta...] >> Sent: Wednesday, February 11, 2009 10:54 PM >> To: wra...@li... >> Cc: Jan, Salman (Salman) >> Subject: Re: [Wrapper-user] wrapper service going down with the >> followingexceptions >> >> Salman, >> I am not able to tell exactly what is happening from what was sent. >> Could you please set the wrapper.debug=true property, delete any >> existing wrapper.log file, then reproduce this. Send me the resulting > >> wrapper.log and wrapper.conf files in entirety as attachments. I >> should then be able to tell you what is happening. >> >> Cheers, >> Leif >> >> On Thu, Feb 12, 2009 at 8:09 AM, Sunkavelli, Sai M (Sai)** CTR ** >> <sai...@al...> wrote: >>> Hi >>> >>> Please help with the following exception in the wrapper log and my >>> java program is terminating after this error. >>> >>> >>> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. >>> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. >>> STATUS | wrapper | 2009/02/11 16:43:16 | <-- Wrapper Stopped >>> >>> Thanks and regards >>> Sai Manohar Sunkavelli. -- Leif Mortenson Representative Director Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel/Fax: +81-3-3878-0415 http://www.tanukisoftware.com lei...@ta... |
|
From: Sunkavelli, S. M \(Sai\)** C. ** <sai...@al...> - 2009-02-19 19:44:30
|
Hi Leif, I changed the path and removed the additional '\' in the path as you suggested below and still we have the problem. Here is the log file with the error, could you please let us know why this is happening. Thanks -Sai -----Original Message----- From: Leif Mortenson [mailto:lei...@ta...] Sent: Saturday, February 14, 2009 10:44 AM To: wra...@li... Cc: Jan, Salman (Salman) Subject: Re: [Wrapper-user] wrapper service going down with thefollowingexceptions Sai, The problem is that the Wrapper's native DLL is not being located correctly. Without that, the wrapper loses the ability to protect the Java process from system logout events. This message should have been visible in your logs even without enabling debug output: --- INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: WARNING - Unable to load the Wrapper's native library because none of the INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: following files: INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: wrapper-windows-x86-64.dll INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: wrapper.dll INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: could be located on the following java.library.path: INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: C:\Program Files\wrapper-delta-pack-3.3.1\lib INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: Please see the documentation for the wrapper.java.library.path INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: configuration property. INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: System signals will not be handled correctly. INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: --- The generated library path is currently set to: -Djava.library.path="C:/Program Files/wrapper-delta-pack-3.3.1\/lib" My guess is that the extra slash before the lib is what is causing your problems. Try removing that by correcting the following in your wrapper.conf: wrapper.java.library.path.1=C:/Program Files/wrapper-delta-pack-3.3.1\/lib Change to: wrapper.java.library.path.1=C:/Program Files/wrapper-delta-pack-3.3.1/lib Let me know how this works for you. Cheers, Leif On Sat, Feb 14, 2009 at 8:47 AM, Sunkavelli, Sai M (Sai)** CTR ** <sai...@al...> wrote: > Hi Leif, > > Here are the log and conf files. Please let us know why this User > logged out error is occurring. > > Thanks > -Sai > > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: Wednesday, February 11, 2009 10:54 PM > To: wra...@li... > Cc: Jan, Salman (Salman) > Subject: Re: [Wrapper-user] wrapper service going down with the > followingexceptions > > Salman, > I am not able to tell exactly what is happening from what was sent. > Could you please set the wrapper.debug=true property, delete any > existing wrapper.log file, then reproduce this. Send me the resulting > wrapper.log and wrapper.conf files in entirety as attachments. I > should then be able to tell you what is happening. > > Cheers, > Leif > > On Thu, Feb 12, 2009 at 8:09 AM, Sunkavelli, Sai M (Sai)** CTR ** > <sai...@al...> wrote: >> Hi >> >> Please help with the following exception in the wrapper log and my >> java program is terminating after this error. >> >> >> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. >> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. >> STATUS | wrapper | 2009/02/11 16:43:16 | <-- Wrapper Stopped >> >> Thanks and regards >> Sai Manohar Sunkavelli. ------------------------------------------------------------------------ ------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Wrapper-user mailing list Wra...@li... https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Leif M. <le...@ta...> - 2009-02-19 14:14:37
|
Holger, Sorry for the delay getting this implemented. It is started, but there are several platforms which need to be supported. I will push it up on my priority list. It is not something which I have noticed personally, But I do understand why you need it. Cheers, Leif On Thu, Feb 19, 2009 at 8:01 PM, Isenberg, Holger <ise...@e-...> wrote: > As everyone who is launching external processes via Runtime.exec() or ProcessBuilder from a large Java-VM might have noticed, there are problems with that approach. During creation of the subprocess, the fork() operating system call is used which duplicates the current Java VM process which might be as large as, say 5GByte. The size of the subprocess is reduced shortly after, but for the time of the creation, twice of the current memory usage is needed or even n times the memory if you launch n processed at the same time. > > Sun describes the problem in the following articles and reports: > > "Minimizing Memory Usage for Creating Application Subprocesses" > http://developers.sun.com/solaris/articles/subprocess/subprocess.html > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5049299 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6381152 > > They describe an approach to use the old fork() from a 2nd (and small) process and as with using the Java wrapper there is already that 2nd process available, it would be nice if the wrapper offers a Java method equivalent to ProcessBuilder() to launch a process and capture its stdout and stderr. > > To capture the stdout/stderr, PipedInputStream and PipedOutputStream using > named pipes could be used. Named pipes are available on any Unix and also on > Windows and can be easily and safely used on Java and C. Redirecting > stdout/stderr in native C on the wrapper side can be done with the Posix > functions pipe() and dup2(). Sample code: > http://www.gidforums.com/t-3369.html . > > A kill-function to stop a runaway child process from Java without the need > to shut down the Java backend should be included in the wrapper, too. That > can use the posix function kill(). > > Wouldn't it be nice, if the wrapper included theses process features? > How many wrapper users would need it? -- Leif Mortenson Representative Director Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel/Fax: +81-3-3878-0415 http://www.tanukisoftware.com lei...@ta... |
|
From: Isenberg, H. <ise...@e-...> - 2009-02-19 11:19:54
|
As everyone who is launching external processes via Runtime.exec() or ProcessBuilder from a large Java-VM might have noticed, there are problems with that approach. During creation of the subprocess, the fork() operating system call is used which duplicates the current Java VM process which might be as large as, say 5GByte. The size of the subprocess is reduced shortly after, but for the time of the creation, twice of the current memory usage is needed or even n times the memory if you launch n processed at the same time. Sun describes the problem in the following articles and reports: "Minimizing Memory Usage for Creating Application Subprocesses" http://developers.sun.com/solaris/articles/subprocess/subprocess.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5049299 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6381152 They describe an approach to use the old fork() from a 2nd (and small) process and as with using the Java wrapper there is already that 2nd process available, it would be nice if the wrapper offers a Java method equivalent to ProcessBuilder() to launch a process and capture its stdout and stderr. To capture the stdout/stderr, PipedInputStream and PipedOutputStream using named pipes could be used. Named pipes are available on any Unix and also on Windows and can be easily and safely used on Java and C. Redirecting stdout/stderr in native C on the wrapper side can be done with the Posix functions pipe() and dup2(). Sample code: http://www.gidforums.com/t-3369.html . A kill-function to stop a runaway child process from Java without the need to shut down the Java backend should be included in the wrapper, too. That can use the posix function kill(). Wouldn't it be nice, if the wrapper included theses process features? How many wrapper users would need it? |
|
From: Tested J. +ve <rak...@gm...> - 2009-02-18 10:58:53
|
Hi Lief, I just want to give you a high level feature of my application. My application starts a exe (for example notepad,silktest ..etc) on a system on which the Service is running,when a user enter's a command I am using Java-RMI technology to do it. What I meant by pop-up is : Now when I am entering a command to start a particular exe,I get a message of interactive services dialog detection and when I click it,it takes me to a screen where it shows the window of the exe opened by the application and prompts me to return to the desktop,after completing my tasks on the opened exe. Can we somehow block this pop-up message and open a exe directly with-out this dialog. I am using a Runtime.exe in my application to start the user command. Also I am using Apache Tomcat in the following way: It displays a page on which user enters the IP and command. I have stored all the specific class files required,for the application to start, do we need to store any kind of Wrapper Specific Files in tomcat's lib directory. Thanks .... Tested Java +ve wrote: > > > Hi all, > > I have a RMI-Application,which runs fine as Standalone.But after starting > the application as a service > it start's the required exe's in process tree but not as a application. > > The Structure is a Client/Administrator will start a particular exe on a > machine on which the Service is running. > > I have created the Service for the RMI-Server specific files using > Wrapper. > > After starting the java.exe process the service starts the exes but in as > process and doesn't pop up the > application window. > > For eg:If I request to start a mspaint the process mspaint.exe starts but > doesnot pop up the paint window... > > Can any one find the bottleneck in this > > Thanks in Advance > > -- View this message in context: http://www.nabble.com/Problem-in-running-the-Application-as-a-Service-tp21972495p22076397.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
|
From: Leif M. <lei...@ta...> - 2009-02-18 10:05:18
|
I am not sure what you are referring to by the desktop pop-up? As for the process tree, what does your wrapper.log look like? My guess is that the Java and Wrapper processes are ending after your child EXE is launched. The Wrapper does not do anything to control child processes and if it is not killed by your java application, it will continue to run in the background. Cheers, Leif On Wed, Feb 18, 2009 at 6:24 PM, Tested Java +ve <rak...@gm...> wrote: > > Hi Leif, > > Thanks for the reply.. > > Hey Cheers its working Now! > > Environment:Windows Vista Ultimate > > I made the following changes to the config file. > > > # Allow the service to interact with the desktop. > wrapper.ntservice.interactive=true > wrapper.ntservice.hide-console=false > > Now when I enter any command,I get a interactive desktop pop-up and I can > work on the started exe. > > Can we somehow stop this pop-up and open the exe directly,without any pop-up > > Also I saw a strange process tree. > > Now their is no java process or any-thing related to java in the process > tree after the service is started. > > Why is this? I am confused how its working !!!!!! without a java process ... > > Thanks > > > Tested Java +ve wrote: >> >> >> Hi all, >> >> I have a RMI-Application,which runs fine as Standalone.But after starting >> the application as a service >> it start's the required exe's in process tree but not as a application. >> >> The Structure is a Client/Administrator will start a particular exe on a >> machine on which the Service is running. >> >> I have created the Service for the RMI-Server specific files using >> Wrapper. >> >> After starting the java.exe process the service starts the exes but in as >> process and doesn't pop up the >> application window. >> >> For eg:If I request to start a mspaint the process mspaint.exe starts but >> doesnot pop up the paint window... >> >> Can any one find the bottleneck in this >> >> Thanks in Advance |
|
From: Tested J. +ve <rak...@gm...> - 2009-02-18 09:25:02
|
Hi Leif, Thanks for the reply.. Hey Cheers its working Now! Environment:Windows Vista Ultimate I made the following changes to the config file. # Allow the service to interact with the desktop. wrapper.ntservice.interactive=true wrapper.ntservice.hide-console=false Now when I enter any command,I get a interactive desktop pop-up and I can work on the started exe. Can we somehow stop this pop-up and open the exe directly,without any pop-up Also I saw a strange process tree. Now their is no java process or any-thing related to java in the process tree after the service is started. Why is this? I am confused how its working !!!!!! without a java process ... Thanks Tested Java +ve wrote: > > > Hi all, > > I have a RMI-Application,which runs fine as Standalone.But after starting > the application as a service > it start's the required exe's in process tree but not as a application. > > The Structure is a Client/Administrator will start a particular exe on a > machine on which the Service is running. > > I have created the Service for the RMI-Server specific files using > Wrapper. > > After starting the java.exe process the service starts the exes but in as > process and doesn't pop up the > application window. > > For eg:If I request to start a mspaint the process mspaint.exe starts but > doesnot pop up the paint window... > > Can any one find the bottleneck in this > > Thanks in Advance > > -- View this message in context: http://www.nabble.com/Problem-in-running-the-Application-as-a-Service-tp21972495p22075087.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
|
From: Leif M. <le...@ta...> - 2009-02-18 08:33:43
|
This could be getting caused by any number of things. I would need more information to say for sure. My first guess is that your service is not being run as an interactive service. That alone would explain why the GUI is not visible. See this page: http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-interactive.html Cheers, Leif On Mon, Feb 16, 2009 at 6:05 PM, Tested Java +ve <rak...@gm...> wrote: > > > Hi all, > > I have a RMI-Application,which runs fine as Standalone.But after starting > the application as a service > it start's the required exe's in process tree but not as a application. > > The Structure is a Client/Administrator will start a particular exe on a > machine on which the Service is running. > > I have created the Service for the RMI-Server specific files using Wrapper. > > After starting the java.exe process the service starts the exes but in as > process and doesn't pop up the > application window. > > For eg:If I request to start a mspaint the process mspaint.exe starts but > doesnot pop up the paint window... > > Can any one find the bottleneck in this > > Thanks in Advance |
|
From: Tested J. +ve <rak...@gm...> - 2009-02-16 09:05:17
|
Hi all, I have a RMI-Application,which runs fine as Standalone.But after starting the application as a service it start's the required exe's in process tree but not as a application. The Structure is a Client/Administrator will start a particular exe on a machine on which the Service is running. I have created the Service for the RMI-Server specific files using Wrapper. After starting the java.exe process the service starts the exes but in as process and doesn't pop up the application window. For eg:If I request to start a mspaint the process mspaint.exe starts but doesnot pop up the paint window... Can any one find the bottleneck in this Thanks in Advance -- View this message in context: http://www.nabble.com/Problem-in-running-the-Application-as-a-Service-tp21972495p21972495.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
|
From: Leif M. <lei...@ta...> - 2009-02-14 15:44:06
|
Sai, The problem is that the Wrapper's native DLL is not being located correctly. Without that, the wrapper loses the ability to protect the Java process from system logout events. This message should have been visible in your logs even without enabling debug output: --- INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: WARNING - Unable to load the Wrapper's native library because none of the INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: following files: INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: wrapper-windows-x86-64.dll INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: wrapper.dll INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: could be located on the following java.library.path: INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: C:\Program Files\wrapper-delta-pack-3.3.1\lib INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: Please see the documentation for the wrapper.java.library.path INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: configuration property. INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: System signals will not be handled correctly. INFO | jvm 1 | 2009/02/12 15:10:11 | WrapperManager: --- The generated library path is currently set to: -Djava.library.path="C:/Program Files/wrapper-delta-pack-3.3.1\/lib" My guess is that the extra slash before the lib is what is causing your problems. Try removing that by correcting the following in your wrapper.conf: wrapper.java.library.path.1=C:/Program Files/wrapper-delta-pack-3.3.1\/lib Change to: wrapper.java.library.path.1=C:/Program Files/wrapper-delta-pack-3.3.1/lib Let me know how this works for you. Cheers, Leif On Sat, Feb 14, 2009 at 8:47 AM, Sunkavelli, Sai M (Sai)** CTR ** <sai...@al...> wrote: > Hi Leif, > > Here are the log and conf files. Please let us know why this User logged > out error is occurring. > > Thanks > -Sai > > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: Wednesday, February 11, 2009 10:54 PM > To: wra...@li... > Cc: Jan, Salman (Salman) > Subject: Re: [Wrapper-user] wrapper service going down with the > followingexceptions > > Salman, > I am not able to tell exactly what is happening from what was sent. > Could you please set the wrapper.debug=true property, delete any > existing wrapper.log file, then reproduce this. Send me the resulting > wrapper.log and wrapper.conf files in entirety as attachments. I should > then be able to tell you what is happening. > > Cheers, > Leif > > On Thu, Feb 12, 2009 at 8:09 AM, Sunkavelli, Sai M (Sai)** CTR ** > <sai...@al...> wrote: >> Hi >> >> Please help with the following exception in the wrapper log and my >> java program is terminating after this error. >> >> >> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. >> INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. >> STATUS | wrapper | 2009/02/11 16:43:16 | <-- Wrapper Stopped >> >> Thanks and regards >> Sai Manohar Sunkavelli. |
|
From: Sunkavelli, S. M \(Sai\)** C. ** <sai...@al...> - 2009-02-13 23:47:42
|
Hi Leif, Here are the log and conf files. Please let us know why this User logged out error is occurring. Thanks -Sai -----Original Message----- From: Leif Mortenson [mailto:lei...@ta...] Sent: Wednesday, February 11, 2009 10:54 PM To: wra...@li... Cc: Jan, Salman (Salman) Subject: Re: [Wrapper-user] wrapper service going down with the followingexceptions Salman, I am not able to tell exactly what is happening from what was sent. Could you please set the wrapper.debug=true property, delete any existing wrapper.log file, then reproduce this. Send me the resulting wrapper.log and wrapper.conf files in entirety as attachments. I should then be able to tell you what is happening. Cheers, Leif On Thu, Feb 12, 2009 at 8:09 AM, Sunkavelli, Sai M (Sai)** CTR ** <sai...@al...> wrote: > Hi > > Please help with the following exception in the wrapper log and my > java program is terminating after this error. > > > INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. > INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. > STATUS | wrapper | 2009/02/11 16:43:16 | <-- Wrapper Stopped > > Thanks and regards > Sai Manohar Sunkavelli. ------------------------------------------------------------------------ ------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Wrapper-user mailing list Wra...@li... https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Leif M. <lei...@ta...> - 2009-02-12 04:02:39
|
Salman, I am not able to tell exactly what is happening from what was sent. Could you please set the wrapper.debug=true property, delete any existing wrapper.log file, then reproduce this. Send me the resulting wrapper.log and wrapper.conf files in entirety as attachments. I should then be able to tell you what is happening. Cheers, Leif On Thu, Feb 12, 2009 at 8:09 AM, Sunkavelli, Sai M (Sai)** CTR ** <sai...@al...> wrote: > Hi > > Please help with the following exception in the wrapper log and my java > program is terminating after this error. > > > INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. > INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. > STATUS | wrapper | 2009/02/11 16:43:16 | <-- Wrapper Stopped > > Thanks and regards > Sai Manohar Sunkavelli. |
|
From: Sunkavelli, S. M \(Sai\)** C. ** <sai...@al...> - 2009-02-11 23:09:33
|
Hi Please help with the following exception in the wrapper log and my java program is terminating after this error. INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. INFO | wrapper | 2009/02/11 16:43:13 | User logged out. Ignored. STATUS | wrapper | 2009/02/11 16:43:16 | <-- Wrapper Stopped Thanks and regards Sai Manohar Sunkavelli. |
|
From: DJP JEAN-P. D. <Dom...@de...> - 2009-02-11 17:11:45
|
Just to say that by desactivating the ping feature, I managed to get my dump. dom -------- Message d'origine-------- De: DJP JEAN-PROST Dominique Date: lun. 09/02/2009 12:01 À: wra...@li... Cc: Leif Mortenson Objet: Re: [Wrapper-user] don't have time to get heap dump Glad to see we understood each other. I will try to desactivate the ping timeout, as getting this dump is getting urgent. regards, dom -----Message d'origine----- De : Leif Mortenson [mailto:le...@ta...] Envoyé : lundi 9 février 2009 11:34 À : DJP JEAN-PROST Dominique Cc : wra...@li... Objet : Re: [Wrapper-user] don't have time to get heap dump Dom, No problem. It is always good to understand what is happening. The ping timeout is used while the JVM application is running normally. How are you initiating your memory dump? I was thinking it was the memory dump that takes place as the JVM is exiting. If the JVM continues after the dump is complete then you are correct, you would want to do something like extend the ping timeout. http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html Cheers, Leif 2009/2/9 DJP JEAN-PROST Dominique <Dom...@de...>: > Leif, > > I will try what you suggest. But as I always try to understand what I do, let me try to reexpose my question. > You explain me the shutdown process of the jvm (hooks, ...). I did use this parameter in another environment because when I stopped the wndows service, jvm shutdown was quite long. > > Now for my OOME : I setup jvm so that if it encounters an memory problem, it creates the memory dump. This setup has nothing to do whith shutdown or something related for what I understand. So what I understand is that when memory problem occurs, jvm tries to make the dump. During this time, jvm does not respond anymore, so wrapper decide to kill the process, and would normally start another one, but I configured it not to because I thought it would let time to the jvm to make the dump : it doesn't. > > I'm not trying to tell your're wrong, but I don't realy understand the motivation of using jvm_exit parameter, and not for instance the ping timeout parameter. > > Can you elaborate about this please ? > best regards, > Dom > > -----Message d'origine----- > De : Leif Mortenson [mailto:le...@ta...] > Envoyé : samedi 7 février 2009 15:09 > À : wra...@li... > Objet : Re: [Wrapper-user] don't have time to get heap dump > > > Dom, > Please try this property: > wrapper.jvm_exit.timeout=600 > > The WrapperManager's shutdown hook makes a call to the native Wrapper > process that the Java application is stopped. From that point, there > is a default 15 second timeout that the Wrapper will wait for the JVM > process to terminate. If it fails to do so then the Wrapper will > forcibly kill it. This is what you are seeing. > The above property extends this timeout. > > When the JVM completes normal operation, it will start doing the full > heap dump. This can take several minutes for large applications. > During this time, the JVM process still exists, but is in a state > which appears to be frozen. > > Cheers, > Leif > > 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: >> Well, when the dump is getting done, the jvm is not trying to exit, so I don't think what you suggest could help me, or I didn't really understand. >> >> For what I understand, jvm gets the oome, it then tries to dump memory on disk, but wrapper does something (it kills the process ?) before the dump gets done. >> >> Where am I worng ? >> dom >> >> -----Message d'origine----- >> De : Leif Mortenson [mailto:le...@ta...] >> Envoyé : vendredi 6 février 2009 17:56 >> À : wra...@li... >> Objet : Re: [Wrapper-user] don't have time to get heap dump >> >> >> Dom, >> The problem here is that the Wrapper itself does not know that the JVM >> is doing a heap dump on exit. It tells the Wrapper that it is >> shutting down but then the java process does not terminate. The >> Wrapper by default waits for 15 seconds before deciding that the java >> process is frozen and kills it. This is what you are seeing. >> >> Normally this is the desired action. In the case of large heap dumps >> however, the timeout needs to be extended. Try adding the following >> to your wrapper.conf: >> >> wrapper.jvm_exit.timeout=600 >> >> That will tell the Wrapper to wait up to 10 minutes for the jvm >> process to exit. Another useful timeout may be: >> >> wrapper.shutdown.timeout=600 >> >> They are both described here: >> http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html >> http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html >> >> Let me know how this works for you. >> Cheers, >> Leif >> >> 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: >>> Hello, >>> >>> I'm actually meeting Out of Memory in my production environment. I configured jvm so that I get a heap dump when the oome is raised. >>> So the I met out of memory, but wrapper did not let jvm the time to dump the heap : >>> >>> INFO | jvm 1 | 2009/02/06 15:56:33 | java.lang.OutOfMemoryError: Java heap space >>> INFO | jvm 1 | 2009/02/06 15:56:33 | Dumping heap to c:\dumps\java_pid2308.hprof ... >>> ERROR | wrapper | 2009/02/06 15:56:48 | JVM appears hung: Timed out waiting for signal from JVM. >>> ERROR | wrapper | 2009/02/06 15:56:48 | JVM did not exit on request, terminated >>> STATUS | wrapper | 2009/02/06 15:56:49 | JVM Restarts disabled. Shutting down. >>> >>> I thought wrapper.disable_restarts=TRUE would let time the jvm to do the dump, but it didn't. >>> What parameter should I use so that I get the full dump ? >>> What would be really cool is that I got the heap dump and that wrapper automatically restart the jvm *after*. >>> >>> Can someone help me ? >>> Best regards, >>> dom Consultez nos nouveaux sites internet : http://www.dexia-sofaxis.com http://www.dexia-sofcap-sofcah.com Tous ensemble pour l’environnement : n’imprimer ce courriel que si nécessaire. Dexia Sofaxis disclaimer : http://www.dexia-sofaxis.com/disclaimer.html |
|
From: Ilya V. <ivo...@cl...> - 2009-02-11 06:58:08
|
Hi, I would like to use names in wrapper configuration that would carry run time information, such as timestamp, random number. The prime reason is to generate various file names for each java invocation (I really need it for gc.log). I could not find anything of the kind. What I suggest is having predefined variables such as %TIMESTAMP%, %RANDOM% much like %WRAPPER_ARCH % etc, but they are evaluated at java invocation time. Is it reasonable? Or something like that already exists? Thank you, Ilya Volvovski |
|
From: DJP JEAN-P. D. <Dom...@de...> - 2009-02-09 11:01:46
|
Glad to see we understood each other. I will try to desactivate the ping timeout, as getting this dump is getting urgent. regards, dom -----Message d'origine----- De : Leif Mortenson [mailto:le...@ta...] Envoyé : lundi 9 février 2009 11:34 À : DJP JEAN-PROST Dominique Cc : wra...@li... Objet : Re: [Wrapper-user] don't have time to get heap dump Dom, No problem. It is always good to understand what is happening. The ping timeout is used while the JVM application is running normally. How are you initiating your memory dump? I was thinking it was the memory dump that takes place as the JVM is exiting. If the JVM continues after the dump is complete then you are correct, you would want to do something like extend the ping timeout. http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html Cheers, Leif 2009/2/9 DJP JEAN-PROST Dominique <Dom...@de...>: > Leif, > > I will try what you suggest. But as I always try to understand what I do, let me try to reexpose my question. > You explain me the shutdown process of the jvm (hooks, ...). I did use this parameter in another environment because when I stopped the wndows service, jvm shutdown was quite long. > > Now for my OOME : I setup jvm so that if it encounters an memory problem, it creates the memory dump. This setup has nothing to do whith shutdown or something related for what I understand. So what I understand is that when memory problem occurs, jvm tries to make the dump. During this time, jvm does not respond anymore, so wrapper decide to kill the process, and would normally start another one, but I configured it not to because I thought it would let time to the jvm to make the dump : it doesn't. > > I'm not trying to tell your're wrong, but I don't realy understand the motivation of using jvm_exit parameter, and not for instance the ping timeout parameter. > > Can you elaborate about this please ? > best regards, > Dom > > -----Message d'origine----- > De : Leif Mortenson [mailto:le...@ta...] > Envoyé : samedi 7 février 2009 15:09 > À : wra...@li... > Objet : Re: [Wrapper-user] don't have time to get heap dump > > > Dom, > Please try this property: > wrapper.jvm_exit.timeout=600 > > The WrapperManager's shutdown hook makes a call to the native Wrapper > process that the Java application is stopped. From that point, there > is a default 15 second timeout that the Wrapper will wait for the JVM > process to terminate. If it fails to do so then the Wrapper will > forcibly kill it. This is what you are seeing. > The above property extends this timeout. > > When the JVM completes normal operation, it will start doing the full > heap dump. This can take several minutes for large applications. > During this time, the JVM process still exists, but is in a state > which appears to be frozen. > > Cheers, > Leif > > 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: >> Well, when the dump is getting done, the jvm is not trying to exit, so I don't think what you suggest could help me, or I didn't really understand. >> >> For what I understand, jvm gets the oome, it then tries to dump memory on disk, but wrapper does something (it kills the process ?) before the dump gets done. >> >> Where am I worng ? >> dom >> >> -----Message d'origine----- >> De : Leif Mortenson [mailto:le...@ta...] >> Envoyé : vendredi 6 février 2009 17:56 >> À : wra...@li... >> Objet : Re: [Wrapper-user] don't have time to get heap dump >> >> >> Dom, >> The problem here is that the Wrapper itself does not know that the JVM >> is doing a heap dump on exit. It tells the Wrapper that it is >> shutting down but then the java process does not terminate. The >> Wrapper by default waits for 15 seconds before deciding that the java >> process is frozen and kills it. This is what you are seeing. >> >> Normally this is the desired action. In the case of large heap dumps >> however, the timeout needs to be extended. Try adding the following >> to your wrapper.conf: >> >> wrapper.jvm_exit.timeout=600 >> >> That will tell the Wrapper to wait up to 10 minutes for the jvm >> process to exit. Another useful timeout may be: >> >> wrapper.shutdown.timeout=600 >> >> They are both described here: >> http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html >> http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html >> >> Let me know how this works for you. >> Cheers, >> Leif >> >> 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: >>> Hello, >>> >>> I'm actually meeting Out of Memory in my production environment. I configured jvm so that I get a heap dump when the oome is raised. >>> So the I met out of memory, but wrapper did not let jvm the time to dump the heap : >>> >>> INFO | jvm 1 | 2009/02/06 15:56:33 | java.lang.OutOfMemoryError: Java heap space >>> INFO | jvm 1 | 2009/02/06 15:56:33 | Dumping heap to c:\dumps\java_pid2308.hprof ... >>> ERROR | wrapper | 2009/02/06 15:56:48 | JVM appears hung: Timed out waiting for signal from JVM. >>> ERROR | wrapper | 2009/02/06 15:56:48 | JVM did not exit on request, terminated >>> STATUS | wrapper | 2009/02/06 15:56:49 | JVM Restarts disabled. Shutting down. >>> >>> I thought wrapper.disable_restarts=TRUE would let time the jvm to do the dump, but it didn't. >>> What parameter should I use so that I get the full dump ? >>> What would be really cool is that I got the heap dump and that wrapper automatically restart the jvm *after*. >>> >>> Can someone help me ? >>> Best regards, >>> dom |
|
From: Leif M. <le...@ta...> - 2009-02-09 10:34:20
|
Dom, No problem. It is always good to understand what is happening. The ping timeout is used while the JVM application is running normally. How are you initiating your memory dump? I was thinking it was the memory dump that takes place as the JVM is exiting. If the JVM continues after the dump is complete then you are correct, you would want to do something like extend the ping timeout. http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html Cheers, Leif 2009/2/9 DJP JEAN-PROST Dominique <Dom...@de...>: > Leif, > > I will try what you suggest. But as I always try to understand what I do, let me try to reexpose my question. > You explain me the shutdown process of the jvm (hooks, ...). I did use this parameter in another environment because when I stopped the wndows service, jvm shutdown was quite long. > > Now for my OOME : I setup jvm so that if it encounters an memory problem, it creates the memory dump. This setup has nothing to do whith shutdown or something related for what I understand. So what I understand is that when memory problem occurs, jvm tries to make the dump. During this time, jvm does not respond anymore, so wrapper decide to kill the process, and would normally start another one, but I configured it not to because I thought it would let time to the jvm to make the dump : it doesn't. > > I'm not trying to tell your're wrong, but I don't realy understand the motivation of using jvm_exit parameter, and not for instance the ping timeout parameter. > > Can you elaborate about this please ? > best regards, > Dom > > -----Message d'origine----- > De : Leif Mortenson [mailto:le...@ta...] > Envoyé : samedi 7 février 2009 15:09 > À : wra...@li... > Objet : Re: [Wrapper-user] don't have time to get heap dump > > > Dom, > Please try this property: > wrapper.jvm_exit.timeout=600 > > The WrapperManager's shutdown hook makes a call to the native Wrapper > process that the Java application is stopped. From that point, there > is a default 15 second timeout that the Wrapper will wait for the JVM > process to terminate. If it fails to do so then the Wrapper will > forcibly kill it. This is what you are seeing. > The above property extends this timeout. > > When the JVM completes normal operation, it will start doing the full > heap dump. This can take several minutes for large applications. > During this time, the JVM process still exists, but is in a state > which appears to be frozen. > > Cheers, > Leif > > 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: >> Well, when the dump is getting done, the jvm is not trying to exit, so I don't think what you suggest could help me, or I didn't really understand. >> >> For what I understand, jvm gets the oome, it then tries to dump memory on disk, but wrapper does something (it kills the process ?) before the dump gets done. >> >> Where am I worng ? >> dom >> >> -----Message d'origine----- >> De : Leif Mortenson [mailto:le...@ta...] >> Envoyé : vendredi 6 février 2009 17:56 >> À : wra...@li... >> Objet : Re: [Wrapper-user] don't have time to get heap dump >> >> >> Dom, >> The problem here is that the Wrapper itself does not know that the JVM >> is doing a heap dump on exit. It tells the Wrapper that it is >> shutting down but then the java process does not terminate. The >> Wrapper by default waits for 15 seconds before deciding that the java >> process is frozen and kills it. This is what you are seeing. >> >> Normally this is the desired action. In the case of large heap dumps >> however, the timeout needs to be extended. Try adding the following >> to your wrapper.conf: >> >> wrapper.jvm_exit.timeout=600 >> >> That will tell the Wrapper to wait up to 10 minutes for the jvm >> process to exit. Another useful timeout may be: >> >> wrapper.shutdown.timeout=600 >> >> They are both described here: >> http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html >> http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html >> >> Let me know how this works for you. >> Cheers, >> Leif >> >> 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: >>> Hello, >>> >>> I'm actually meeting Out of Memory in my production environment. I configured jvm so that I get a heap dump when the oome is raised. >>> So the I met out of memory, but wrapper did not let jvm the time to dump the heap : >>> >>> INFO | jvm 1 | 2009/02/06 15:56:33 | java.lang.OutOfMemoryError: Java heap space >>> INFO | jvm 1 | 2009/02/06 15:56:33 | Dumping heap to c:\dumps\java_pid2308.hprof ... >>> ERROR | wrapper | 2009/02/06 15:56:48 | JVM appears hung: Timed out waiting for signal from JVM. >>> ERROR | wrapper | 2009/02/06 15:56:48 | JVM did not exit on request, terminated >>> STATUS | wrapper | 2009/02/06 15:56:49 | JVM Restarts disabled. Shutting down. >>> >>> I thought wrapper.disable_restarts=TRUE would let time the jvm to do the dump, but it didn't. >>> What parameter should I use so that I get the full dump ? >>> What would be really cool is that I got the heap dump and that wrapper automatically restart the jvm *after*. >>> >>> Can someone help me ? >>> Best regards, >>> dom |
|
From: DJP JEAN-P. D. <Dom...@de...> - 2009-02-09 08:23:54
|
Leif, I will try what you suggest. But as I always try to understand what I do, let me try to reexpose my question. You explain me the shutdown process of the jvm (hooks, ...). I did use this parameter in another environment because when I stopped the wndows service, jvm shutdown was quite long. Now for my OOME : I setup jvm so that if it encounters an memory problem, it creates the memory dump. This setup has nothing to do whith shutdown or something related for what I understand. So what I understand is that when memory problem occurs, jvm tries to make the dump. During this time, jvm does not respond anymore, so wrapper decide to kill the process, and would normally start another one, but I configured it not to because I thought it would let time to the jvm to make the dump : it doesn't. I'm not trying to tell your're wrong, but I don't realy understand the motivation of using jvm_exit parameter, and not for instance the ping timeout parameter. Can you elaborate about this please ? best regards, Dom -----Message d'origine----- De : Leif Mortenson [mailto:le...@ta...] Envoyé : samedi 7 février 2009 15:09 À : wra...@li... Objet : Re: [Wrapper-user] don't have time to get heap dump Dom, Please try this property: wrapper.jvm_exit.timeout=600 The WrapperManager's shutdown hook makes a call to the native Wrapper process that the Java application is stopped. From that point, there is a default 15 second timeout that the Wrapper will wait for the JVM process to terminate. If it fails to do so then the Wrapper will forcibly kill it. This is what you are seeing. The above property extends this timeout. When the JVM completes normal operation, it will start doing the full heap dump. This can take several minutes for large applications. During this time, the JVM process still exists, but is in a state which appears to be frozen. Cheers, Leif 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: > Well, when the dump is getting done, the jvm is not trying to exit, so I don't think what you suggest could help me, or I didn't really understand. > > For what I understand, jvm gets the oome, it then tries to dump memory on disk, but wrapper does something (it kills the process ?) before the dump gets done. > > Where am I worng ? > dom > > -----Message d'origine----- > De : Leif Mortenson [mailto:le...@ta...] > Envoyé : vendredi 6 février 2009 17:56 > À : wra...@li... > Objet : Re: [Wrapper-user] don't have time to get heap dump > > > Dom, > The problem here is that the Wrapper itself does not know that the JVM > is doing a heap dump on exit. It tells the Wrapper that it is > shutting down but then the java process does not terminate. The > Wrapper by default waits for 15 seconds before deciding that the java > process is frozen and kills it. This is what you are seeing. > > Normally this is the desired action. In the case of large heap dumps > however, the timeout needs to be extended. Try adding the following > to your wrapper.conf: > > wrapper.jvm_exit.timeout=600 > > That will tell the Wrapper to wait up to 10 minutes for the jvm > process to exit. Another useful timeout may be: > > wrapper.shutdown.timeout=600 > > They are both described here: > http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html > http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html > > Let me know how this works for you. > Cheers, > Leif > > 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: >> Hello, >> >> I'm actually meeting Out of Memory in my production environment. I configured jvm so that I get a heap dump when the oome is raised. >> So the I met out of memory, but wrapper did not let jvm the time to dump the heap : >> >> INFO | jvm 1 | 2009/02/06 15:56:33 | java.lang.OutOfMemoryError: Java heap space >> INFO | jvm 1 | 2009/02/06 15:56:33 | Dumping heap to c:\dumps\java_pid2308.hprof ... >> ERROR | wrapper | 2009/02/06 15:56:48 | JVM appears hung: Timed out waiting for signal from JVM. >> ERROR | wrapper | 2009/02/06 15:56:48 | JVM did not exit on request, terminated >> STATUS | wrapper | 2009/02/06 15:56:49 | JVM Restarts disabled. Shutting down. >> >> I thought wrapper.disable_restarts=TRUE would let time the jvm to do the dump, but it didn't. >> What parameter should I use so that I get the full dump ? >> What would be really cool is that I got the heap dump and that wrapper automatically restart the jvm *after*. >> >> Can someone help me ? >> Best regards, >> dom ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Wrapper-user mailing list Wra...@li... https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Leif M. <le...@ta...> - 2009-02-07 14:09:28
|
Dom, Please try this property: wrapper.jvm_exit.timeout=600 The WrapperManager's shutdown hook makes a call to the native Wrapper process that the Java application is stopped. From that point, there is a default 15 second timeout that the Wrapper will wait for the JVM process to terminate. If it fails to do so then the Wrapper will forcibly kill it. This is what you are seeing. The above property extends this timeout. When the JVM completes normal operation, it will start doing the full heap dump. This can take several minutes for large applications. During this time, the JVM process still exists, but is in a state which appears to be frozen. Cheers, Leif 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: > Well, when the dump is getting done, the jvm is not trying to exit, so I don't think what you suggest could help me, or I didn't really understand. > > For what I understand, jvm gets the oome, it then tries to dump memory on disk, but wrapper does something (it kills the process ?) before the dump gets done. > > Where am I worng ? > dom > > -----Message d'origine----- > De : Leif Mortenson [mailto:le...@ta...] > Envoyé : vendredi 6 février 2009 17:56 > À : wra...@li... > Objet : Re: [Wrapper-user] don't have time to get heap dump > > > Dom, > The problem here is that the Wrapper itself does not know that the JVM > is doing a heap dump on exit. It tells the Wrapper that it is > shutting down but then the java process does not terminate. The > Wrapper by default waits for 15 seconds before deciding that the java > process is frozen and kills it. This is what you are seeing. > > Normally this is the desired action. In the case of large heap dumps > however, the timeout needs to be extended. Try adding the following > to your wrapper.conf: > > wrapper.jvm_exit.timeout=600 > > That will tell the Wrapper to wait up to 10 minutes for the jvm > process to exit. Another useful timeout may be: > > wrapper.shutdown.timeout=600 > > They are both described here: > http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html > http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html > > Let me know how this works for you. > Cheers, > Leif > > 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: >> Hello, >> >> I'm actually meeting Out of Memory in my production environment. I configured jvm so that I get a heap dump when the oome is raised. >> So the I met out of memory, but wrapper did not let jvm the time to dump the heap : >> >> INFO | jvm 1 | 2009/02/06 15:56:33 | java.lang.OutOfMemoryError: Java heap space >> INFO | jvm 1 | 2009/02/06 15:56:33 | Dumping heap to c:\dumps\java_pid2308.hprof ... >> ERROR | wrapper | 2009/02/06 15:56:48 | JVM appears hung: Timed out waiting for signal from JVM. >> ERROR | wrapper | 2009/02/06 15:56:48 | JVM did not exit on request, terminated >> STATUS | wrapper | 2009/02/06 15:56:49 | JVM Restarts disabled. Shutting down. >> >> I thought wrapper.disable_restarts=TRUE would let time the jvm to do the dump, but it didn't. >> What parameter should I use so that I get the full dump ? >> What would be really cool is that I got the heap dump and that wrapper automatically restart the jvm *after*. >> >> Can someone help me ? >> Best regards, >> dom |
|
From: DJP JEAN-P. D. <Dom...@de...> - 2009-02-06 17:16:14
|
Well, when the dump is getting done, the jvm is not trying to exit, so I don't think what you suggest could help me, or I didn't really understand. For what I understand, jvm gets the oome, it then tries to dump memory on disk, but wrapper does something (it kills the process ?) before the dump gets done. Where am I worng ? dom -----Message d'origine----- De : Leif Mortenson [mailto:le...@ta...] Envoyé : vendredi 6 février 2009 17:56 À : wra...@li... Objet : Re: [Wrapper-user] don't have time to get heap dump Dom, The problem here is that the Wrapper itself does not know that the JVM is doing a heap dump on exit. It tells the Wrapper that it is shutting down but then the java process does not terminate. The Wrapper by default waits for 15 seconds before deciding that the java process is frozen and kills it. This is what you are seeing. Normally this is the desired action. In the case of large heap dumps however, the timeout needs to be extended. Try adding the following to your wrapper.conf: wrapper.jvm_exit.timeout=600 That will tell the Wrapper to wait up to 10 minutes for the jvm process to exit. Another useful timeout may be: wrapper.shutdown.timeout=600 They are both described here: http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html Let me know how this works for you. Cheers, Leif 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: > Hello, > > I'm actually meeting Out of Memory in my production environment. I configured jvm so that I get a heap dump when the oome is raised. > So the I met out of memory, but wrapper did not let jvm the time to dump the heap : > > INFO | jvm 1 | 2009/02/06 15:56:33 | java.lang.OutOfMemoryError: Java heap space > INFO | jvm 1 | 2009/02/06 15:56:33 | Dumping heap to c:\dumps\java_pid2308.hprof ... > ERROR | wrapper | 2009/02/06 15:56:48 | JVM appears hung: Timed out waiting for signal from JVM. > ERROR | wrapper | 2009/02/06 15:56:48 | JVM did not exit on request, terminated > STATUS | wrapper | 2009/02/06 15:56:49 | JVM Restarts disabled. Shutting down. > > I thought wrapper.disable_restarts=TRUE would let time the jvm to do the dump, but it didn't. > What parameter should I use so that I get the full dump ? > What would be really cool is that I got the heap dump and that wrapper automatically restart the jvm *after*. > > Can someone help me ? > Best regards, > dom > Consultez nos nouveaux sites internet : > http://www.dexia-sofaxis.com > http://www.dexia-sofcap-sofcah.com > > Tous ensemble pour l'environnement : n'imprimer ce courriel que si nécessaire. > > Dexia Sofaxis disclaimer : http://www.dexia-sofaxis.com/disclaimer.html ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Wrapper-user mailing list Wra...@li... https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Leif M. <le...@ta...> - 2009-02-06 16:56:21
|
Dom, The problem here is that the Wrapper itself does not know that the JVM is doing a heap dump on exit. It tells the Wrapper that it is shutting down but then the java process does not terminate. The Wrapper by default waits for 15 seconds before deciding that the java process is frozen and kills it. This is what you are seeing. Normally this is the desired action. In the case of large heap dumps however, the timeout needs to be extended. Try adding the following to your wrapper.conf: wrapper.jvm_exit.timeout=600 That will tell the Wrapper to wait up to 10 minutes for the jvm process to exit. Another useful timeout may be: wrapper.shutdown.timeout=600 They are both described here: http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html Let me know how this works for you. Cheers, Leif 2009/2/7 DJP JEAN-PROST Dominique <Dom...@de...>: > Hello, > > I'm actually meeting Out of Memory in my production environment. I configured jvm so that I get a heap dump when the oome is raised. > So the I met out of memory, but wrapper did not let jvm the time to dump the heap : > > INFO | jvm 1 | 2009/02/06 15:56:33 | java.lang.OutOfMemoryError: Java heap space > INFO | jvm 1 | 2009/02/06 15:56:33 | Dumping heap to c:\dumps\java_pid2308.hprof ... > ERROR | wrapper | 2009/02/06 15:56:48 | JVM appears hung: Timed out waiting for signal from JVM. > ERROR | wrapper | 2009/02/06 15:56:48 | JVM did not exit on request, terminated > STATUS | wrapper | 2009/02/06 15:56:49 | JVM Restarts disabled. Shutting down. > > I thought wrapper.disable_restarts=TRUE would let time the jvm to do the dump, but it didn't. > What parameter should I use so that I get the full dump ? > What would be really cool is that I got the heap dump and that wrapper automatically restart the jvm *after*. > > Can someone help me ? > Best regards, > dom > Consultez nos nouveaux sites internet : > http://www.dexia-sofaxis.com > http://www.dexia-sofcap-sofcah.com > > Tous ensemble pour l'environnement : n'imprimer ce courriel que si nécessaire. > > Dexia Sofaxis disclaimer : http://www.dexia-sofaxis.com/disclaimer.html |
|
From: DJP JEAN-P. D. <Dom...@de...> - 2009-02-06 16:05:32
|
Hello, I'm actually meeting Out of Memory in my production environment. I configured jvm so that I get a heap dump when the oome is raised. So the I met out of memory, but wrapper did not let jvm the time to dump the heap : INFO | jvm 1 | 2009/02/06 15:56:33 | java.lang.OutOfMemoryError: Java heap space INFO | jvm 1 | 2009/02/06 15:56:33 | Dumping heap to c:\dumps\java_pid2308.hprof ... ERROR | wrapper | 2009/02/06 15:56:48 | JVM appears hung: Timed out waiting for signal from JVM. ERROR | wrapper | 2009/02/06 15:56:48 | JVM did not exit on request, terminated STATUS | wrapper | 2009/02/06 15:56:49 | JVM Restarts disabled. Shutting down. I thought wrapper.disable_restarts=TRUE would let time the jvm to do the dump, but it didn't. What parameter should I use so that I get the full dump ? What would be really cool is that I got the heap dump and that wrapper automatically restart the jvm *after*. Can someone help me ? Best regards, dom |
165 messages has been excluded from this view by a project administrator.
