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: Andreas K. <and...@ya...> - 2009-05-04 14:38:10
|
Hi again, So now the server has crashed again - running longer than before thanks to the extended timout limit. The app eats memory and reports about low memory for days before the actual crash. The home made garbage collector thread takes 50% of processor-load also for days before the crash. I saw once in the log that the GC-succeeded to reduce the memory used significantly and the wrapper complained about it taking long time and increasing its limits. Here is a snap of the log prior to the crash. Any hints on how to debug this is highly appreciated;) brgds Andreas ************************************************************ ************************************************************ 2009/05/01 10:29:32 | send a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:32 | Received a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:32 | Send a packet PING : ok DEBUG | wrapperp | 2009/05/01 10:29:32 | read a packet PING : ok DEBUG | wrapper | 2009/05/01 10:29:32 | Got ping response from JVM INFO | jvm 1 | 2009/05/01 10:29:34 | 256520976 2009-05-01 10:29:34,894 WARN com.sse.supervisor.SSESupervisor ** Low of memory [0]mb free ! SSEGarbageCollect will occur. INFO | jvm 1 | 2009/05/01 10:29:36 | 2395102070 2009-05-01 10:29:36,191 WARN com.sse.supervisor.SSESupervisor ***** Real low of memory [0]mb free!!! Will garbagecollect all singletons and throwing out old members. INFO | jvm 1 | 2009/05/01 10:29:37 | 727880698 2009-05-01 10:29:37,472 ERROR com.sse.supervisor.SSESupervisor *************************** OUT OF MEMORY *** WILL DIE ***************************** DEBUG | wrapperp | 2009/05/01 10:29:38 | send a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:38 | Received a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:38 | Send a packet PING : ok INFO | jvm 1 | 2009/05/01 10:29:38 | 176404686 2009-05-01 10:29:38,769 WARN com.sse.thread.SSEThreadManager 1604 long living threads alive (warn limit = 25) DEBUG | wrapperp | 2009/05/01 10:29:38 | read a packet PING : ok DEBUG | wrapper | 2009/05/01 10:29:38 | Got ping response from JVM INFO | jvm 1 | 2009/05/01 10:29:43 | 4102609922 2009-05-01 10:29:42,644 WARN com.sse.supervisor.SSESupervisor ** Low of memory [0]mb free ! SSEGarbageCollect will occur. DEBUG | wrapperp | 2009/05/01 10:29:44 | send a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:45 | Received a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:45 | Send a packet PING : ok INFO | jvm 1 | 2009/05/01 10:29:45 | 3599369368 2009-05-01 10:29:45,207 WARN com.sse.supervisor.SSESupervisor ***** Real low of memory [0]mb free!!! Will garbagecollect all singletons and throwing out old members. DEBUG | wrapperp | 2009/05/01 10:29:45 | read a packet PING : ok DEBUG | wrapper | 2009/05/01 10:29:45 | Got ping response from JVM INFO | jvm 1 | 2009/05/01 10:29:49 | 1881161018 2009-05-01 10:29:47,801 ERROR com.sse.supervisor.SSESupervisor *************************** OUT OF MEMORY *** WILL DIE ***************************** DEBUG | wrapperp | 2009/05/01 10:29:50 | send a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:50 | Received a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:50 | Send a packet PING : ok DEBUG | wrapperp | 2009/05/01 10:29:50 | read a packet PING : ok DEBUG | wrapper | 2009/05/01 10:29:50 | Got ping response from JVM DEBUG | wrapperp | 2009/05/01 10:29:56 | send a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:56 | Received a packet PING : ping INFO | jvm 1 | 2009/05/01 10:29:56 | Send a packet PING : ok DEBUG | wrapperp | 2009/05/01 10:29:56 | read a packet PING : ok DEBUG | wrapper | 2009/05/01 10:29:56 | Got ping response from JVM INFO | jvm 1 | 2009/05/01 10:29:59 | 1644323367 2009-05-01 10:29:49,097 WARN com.sse.thread.SSEThreadManager 1605 long living threads alive (warn limit = 25) DEBUG | wrapperp | 2009/05/01 10:30:02 | send a packet PING : ping INFO | jvm 1 | 2009/05/01 10:30:03 | Closing socket. INFO | jvm 1 | 2009/05/01 10:30:03 | 1959232901 2009-05-01 10:29:54,254 WARN com.sse.thread.SSEATThread ATWork jammed: SSEGarbageWrapper: [java.lang.ref.WeakReference@1662402] INFO | jvm 1 | 2009/05/01 10:30:03 | Server daemon died! INFO | jvm 1 | 2009/05/01 10:30:03 | java.lang.OutOfMemoryError INFO | jvm 1 | 2009/05/01 10:30:03 | Open socket to wrapper... DEBUG | wrapperp | 2009/05/01 10:30:03 | socket read no code (closed?). DEBUG | wrapperp | 2009/05/01 10:30:03 | accepted a socket from 127.0.0.1 on port 2779 INFO | jvm 1 | 2009/05/01 10:30:07 | Opened Socket INFO | jvm 1 | 2009/05/01 10:30:07 | Send a packet KEY : iRUaWR2l6u5k5Rdr DEBUG | wrapperp | 2009/05/01 10:30:07 | read a packet KEY : iRUaWR2l6u5k5Rdr DEBUG | wrapper | 2009/05/01 10:30:07 | Got key from JVM: iRUaWR2l6u5k5Rdr DEBUG | wrapperp | 2009/05/01 10:30:08 | send a packet PING : ping INFO | jvm 1 | 2009/05/01 10:30:10 | INFO | jvm 1 | 2009/05/01 10:30:11 | Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6D3A5947 INFO | jvm 1 | 2009/05/01 10:30:11 | Function=[Unknown.] INFO | jvm 1 | 2009/05/01 10:30:11 | Library=C:\Program Files\Singleton\knahem\jre\bin\client\jvm.dll INFO | jvm 1 | 2009/05/01 10:30:11 | INFO | jvm 1 | 2009/05/01 10:30:11 | NOTE: We are unable to locate the function name symbol for the error INFO | jvm 1 | 2009/05/01 10:30:11 | just occurred. Please refer to release documentation for possible INFO | jvm 1 | 2009/05/01 10:30:11 | reason and solutions. INFO | jvm 1 | 2009/05/01 10:30:11 | INFO | jvm 1 | 2009/05/01 10:30:11 | INFO | jvm 1 | 2009/05/01 10:30:11 | Current Java thread: INFO | jvm 1 | 2009/05/01 10:30:11 | at java.net.PlainSocketImpl.socketAccept(Native Method) INFO | jvm 1 | 2009/05/01 10:30:11 | at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353) INFO | jvm 1 | 2009/05/01 10:30:11 | - locked <03C62228> (a java.net.PlainSocketImpl) INFO | jvm 1 | 2009/05/01 10:30:11 | at java.net.ServerSocket.implAccept(ServerSocket.java:439) INFO | jvm 1 | 2009/05/01 10:30:11 | at java.net.ServerSocket.accept(ServerSocket.java:410) INFO | jvm 1 | 2009/05/01 10:30:11 | at org.mortbay.util.ThreadedServer.acceptSocket(ThreadedServer.java:346) INFO | jvm 1 | 2009/05/01 10:30:11 | at org.mortbay.util.ThreadedServer$Acceptor.run(ThreadedServer.java:523) INFO | jvm 1 | 2009/05/01 10:30:11 | INFO | jvm 1 | 2009/05/01 10:30:11 | Dynamic libraries: INFO | jvm 1 | 2009/05/01 10:30:11 | 0x00400000 - 0x00406000 C:\Program Files\Singleton\knahem\jre\bin\java.exe INFO | jvm 1 | 2009/05/01 10:30:11 | 0x7C800000 - 0x7C8C2000 C:\WINDOWS\system32\ntdll.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x77E40000 - 0x77F42000 C:\WINDOWS\system32\kernel32.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x7D1E0000 - 0x7D27C000 C:\WINDOWS\system32\ADVAPI32.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x77C50000 - 0x77CEF000 C:\WINDOWS\system32\RPCRT4.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x76F50000 - 0x76F63000 C:\WINDOWS\system32\Secur32.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x77BA0000 - 0x77BFA000 C:\WINDOWS\system32\MSVCRT.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x6D330000 - 0x6D45A000 C:\Program Files\Singleton\knahem\jre\bin\client\jvm.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x77380000 - 0x77411000 C:\WINDOWS\system32\USER32.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x77C00000 - 0x77C49000 C:\WINDOWS\system32\GDI32.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x76AA0000 - 0x76ACD000 C:\WINDOWS\system32\WINMM.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x6D1D0000 - 0x6D1D7000 C:\Program Files\Singleton\knahem\jre\bin\hpi.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x6D300000 - 0x6D30D000 C:\Program Files\Singleton\knahem\jre\bin\verify.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x6D210000 - 0x6D229000 C:\Program Files\Singleton\knahem\jre\bin\java.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x6D320000 - 0x6D32D000 C:\Program Files\Singleton\knahem\jre\bin\zip.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x16C10000 - 0x16C1E000 C:\Program Files\Singleton\knahem\jar\Wrapper.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x6D2D0000 - 0x6D2DE000 C:\Program Files\Singleton\knahem\jre\bin\net.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x71BB0000 - 0x71BB9000 C:\WINDOWS\system32\WSOCK32.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x71C00000 - 0x71C17000 C:\WINDOWS\system32\WS2_32.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x71BF0000 - 0x71BF8000 C:\WINDOWS\system32\WS2HELP.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x71B20000 - 0x71B61000 C:\WINDOWS\system32\mswsock.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x5F270000 - 0x5F2CA000 C:\WINDOWS\system32\hnetcfg.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x71AE0000 - 0x71AE8000 C:\WINDOWS\System32\wshtcpip.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x76ED0000 - 0x76EFA000 C:\WINDOWS\system32\DNSAPI.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x76F70000 - 0x76F77000 C:\WINDOWS\System32\winrnr.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x76F10000 - 0x76F3E000 C:\WINDOWS\system32\WLDAP32.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x76F80000 - 0x76F85000 C:\WINDOWS\system32\rasadhlp.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x76C10000 - 0x76C38000 C:\WINDOWS\system32\imagehlp.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x6D580000 - 0x6D628000 C:\WINDOWS\system32\dbghelp.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x77B90000 - 0x77B98000 C:\WINDOWS\system32\VERSION.dll INFO | jvm 1 | 2009/05/01 10:30:11 | 0x76B70000 - 0x76B7B000 C:\WINDOWS\system32\PSAPI.DLL INFO | jvm 1 | 2009/05/01 10:30:11 | INFO | jvm 1 | 2009/05/01 10:30:11 | Local Time = Fri May 01 10:30:10 2009 INFO | jvm 1 | 2009/05/01 10:30:11 | Elapsed Time = 1073809 INFO | jvm 1 | 2009/05/01 10:30:11 | # INFO | jvm 1 | 2009/05/01 10:30:11 | # HotSpot Virtual Machine Error : EXCEPTION_ACCESS_VIOLATION INFO | jvm 1 | 2009/05/01 10:30:11 | # Error ID : 4F530E43505002E6 INFO | jvm 1 | 2009/05/01 10:30:11 | # Please report this error at INFO | jvm 1 | 2009/05/01 10:30:11 | # http://java.sun.com/cgi-bin/bugreport.cgi INFO | jvm 1 | 2009/05/01 10:30:11 | # INFO | jvm 1 | 2009/05/01 10:30:11 | # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) INFO | jvm 1 | 2009/05/01 10:30:11 | # INFO | jvm 1 | 2009/05/01 10:30:11 | # An error report file has been saved as hs_err_pid1416.log. INFO | jvm 1 | 2009/05/01 10:30:11 | # Please refer to the file for further information. INFO | jvm 1 | 2009/05/01 10:30:11 | # ERROR | wrapper | 2009/05/01 10:30:11 | JVM exited unexpectedly. STATUS | wrapper | 2009/05/01 10:30:18 | Launching a JVM... DEBUG | wrapper | 2009/05/01 10:30:18 | command: ".\jre\bin\java.exe" -Xms96m -Xmx256m -Djava.library.path="jar" -classpath "jar/wrapper.jar;bin;jar/scm/jndi.zip;jar/scm/xmlParserAPIs.jar;jar/scm/xml-apis.jar;jar/scm/xercesImpl.jar;jar/scm/org.mortbay.jmx.jar;jar/scm/org.mortbay.jetty.jar;jar/scm/msutil.jar;jar/scm/mssqlserver.jar;jar/scm/msbase.jar;jar/scm/mail.jar;jar/scm/log4j-1.2.8.jar;jar/scm/jsse.jar;jar/scm/jnet.jar;jar/scm/jmxtools.jar;jar/scm/jmxri.jar;jar/scm/jcert.jar;jar/scm/javax.servlet.jar;jar/scm/jasper-runtime.jar;jar/scm/jasper-compiler.jar;jar/scm/ant.jar;jar/scm/activation.jar;jar/scm/jta.zip;jar/scm/nls_charset12.zip;jar/scm/jxl.jar" -Dwrapper.key="__cnKEm_eo5rsqvD" -Dwrapper.port=32000 -Dwrapper.debug="TRUE" -Dwrapper.service="TRUE" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=2 org.tanukisoftware.wrapper.WrapperSimpleApp com.scm.main.WebServer khm DEBUG | wrapper | 2009/05/01 10:30:18 | Java Virtual Machine started (PID=8972) INFO | jvm 2 | 2009/05/01 10:30:20 | Wrapper Manager: JVM #2 INFO | jvm 2 | 2009/05/01 10:30:20 | Wrapper Manager: Registering shutdown hook INFO | jvm 2 | 2009/05/01 10:30:20 | Wrapper Manager: Using wrapper INFO | jvm 2 | 2009/05/01 10:30:20 | Calling native initialization method. INFO | jvm 2 | 2009/05/01 10:30:20 | Initializing WrapperManager native library. INFO | jvm 2 | 2009/05/01 10:30:20 | Java Executable: C:\Program Files\Singleton\knahem\jre\bin\java.exe INFO | jvm 2 | 2009/05/01 10:30:20 | Java Version : 1.4.1_01-b01 Java HotSpot(TM) Client VM INFO | jvm 2 | 2009/05/01 10:30:20 | Java VM Vendor : Sun Microsystems Inc. INFO | jvm 2 | 2009/05/01 10:30:20 | INFO | jvm 2 | 2009/05/01 10:30:20 | Wrapper (Version 3.0.5) INFO | jvm 2 | 2009/05/01 10:30:20 | INFO | jvm 2 | 2009/05/01 10:30:20 | Open socket to wrapper... INFO | jvm 2 | 2009/05/01 10:30:20 | Opened Socket INFO | jvm 2 | 2009/05/01 10:30:20 | Send a packet KEY : __cnKEm_eo5rsqvD INFO | jvm 2 | 2009/05/01 10:30:20 | handleSocket(Socket[addr=/127.0.0.1,port=32000,localport=2780]) DEBUG | wrapperp | 2009/05/01 10:30:20 | accepted a socket from 127.0.0.1 on port 2780 DEBUG | wrapperp | 2009/05/01 10:30:20 | read a packet KEY : __cnKEm_eo5rsqvD DEBUG | wrapper | 2009/05/01 10:30:20 | Got key from JVM: __cnKEm_eo5rsqvD DEBUG | wrapperp | 2009/05/01 10:30:20 | send a packet LOW_LOG_LEVEL : 1 DEBUG | wrapperp | 2009/05/01 10:30:20 | send a packet PING_TIMEOUT : 120 DEBUG | wrapper | 2009/05/01 10:30:20 | Start Application. DEBUG | wrapperp | 2009/05/01 10:30:20 | send a packet START : start INFO | jvm 2 | 2009/05/01 10:30:21 | Received a packet LOW_LOG_LEVEL : 1 INFO | jvm 2 | 2009/05/01 10:30:21 | Wrapper Manager: LowLogLevel from Wrapper is 1 INFO | jvm 2 | 2009/05/01 10:30:21 | Received a packet PING_TIMEOUT : 120 INFO | jvm 2 | 2009/05/01 10:30:21 | Wrapper Manager: PingTimeout from Wrapper is 120000 INFO | jvm 2 | 2009/05/01 10:30:21 | Received a packet START : start INFO | jvm 2 | 2009/05/01 10:30:21 | calling listener.start() INFO | jvm 2 | 2009/05/01 10:30:21 | WrapperSimpleApp: start(args) INFO | jvm 2 | 2009/05/01 10:30:21 | WrapperSimpleApp: invoking main method INFO | jvm 2 | 2009/05/01 10:30:22 | 1 2009-05-01 10:30:22,285 INFO com.sse.thread.SSEThreadManager SSEThreadManager created ****************************************************** ****************************************************** ****************************************************** --- Leif Mortenson <lei...@ta...> wrote: > Andreas, > One think that you have to be very careful of is to make sure that the > JVM is never forced to swap any of its memory to disk. This is > nothing related to the Wrapper. But Java gets VERY VERY VERY slow > when its memory is being swapped. It is common for 1/1000 affect on > performance. It may be possible that your new database is using a > lot more memory and thus forcing the JVM to swap. > > Take a look at your task manager and make sure you have enough memory. > I will see if there is any way that I can tell when this is happening > to Java and warn the user about it in the log. > > Cheers, > Leif > > On Fri, Apr 17, 2009 at 5:02 PM, Andreas Karlsson > <and...@ya...> wrote: > > > > Hi Leif, > > I've restarted it with the setting you suggested. > > The problem shows up at any time between 7-10 days from last restart. > > Often the application complains about low memory and performs garbage collection > > prior to that. > > I've been fiddling with the memory settings and now they should be the same for > the > > server-jvm-wrapper but the error still occurs. > > I'll get back to you next week when it has restarted again. > > brgds > > Andreas > > > > --- Leif Mortenson <le...@ta...> wrote: > > > >> Andreas, > >> Most likely the Java process is being starved of CPU and that is > >> leading to the Wrapper thinking it is frozen. If that is the case > >> then you can easily resolve the problem by setting the following > >> property: > >> wrapper.ping.timeout=120 > >> (http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html) > >> > >> That will tell the Wrapper to allow the JVM to be frozen for 120 > >> seconds before it is killed. The default is 30 seconds. > >> > >> However, your web site would be unresponsive during that period still. > >> Most likely it is now for at least 30 seconds. Do the restarts > >> happen at any particular time each week? Is there some large DB > >> processing being done that is consuming all of the CPU? It may be > >> necessary to move the Database over to another physical server to make > >> sure your app server is not being affected by that processing. > >> > >> If you set the wrapper.debug=TRUE property and then reproduce this, I > >> might be able to tell you a little more information about what is > >> happening prior to the restart. I would only need the 3-5 minutes of > >> time prior to the Wrapper timing out and killing the JVM. > >> > >> There have also been several bugs fixed since 3.0.5 which could affect > >> this. Please review the release-notes: > >> http://wrapper.tanukisoftware.org/doc/english/release-notes.html > >> > >> Cheers, > >> Leif > >> > >> On Thu, Apr 16, 2009 at 5:55 PM, Andreas Karlsson > >> <and...@ya...> wrote: > >> > > >> > Hi wrapper-folks! > >> > I would love some hints and ideas on how to debug this problem and find a > >> solution. > >> > > >> > The system is a > >> > - windows server 2003 > >> > - jettyserver > >> > - java 1.4.1 > >> > - wrapper 3.0.5 > >> > > >> > It has been running for years without any problems. But after some updates of > >> the > >> > data in the database where the web-content is stored and a recompile of the > code > >> it > >> > started to produce these messages (pasted below). It happens approximately > once > >> > every week. > >> > How can I debug this? > >> > Is there a way to trigg a dump when it happens? > >> > > >> > > >> > ERROR | wrapper | 2009/04/15 10:17:07 | JVM appears hung: Timed out waiting > >> for > >> > signal from JVM. > >> > ERROR | wrapper | 2009/04/15 10:17:07 | Java Virtual Machine did not exit > on > >> > request, terminated > >> > STATUS | wrapper | 2009/04/15 10:17:13 | Launching a JVM... > >> > INFO | jvm 2 | 2009/04/15 10:17:14 | Wrapper (Version 3.0.5) > >> > > >> > brgds > >> > Andreas > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Leif M. <le...@ta...> - 2009-04-30 07:35:28
|
John, I am not clear what exactly your security scanner did to test the Wrapper. The Wrapper is used to launch various Java based applications and does not have an HTTP interface directly. It is possible that your security scanner is actually having a problem with the application run under the wrapper. The Wrapper itself is able to access parent directories to access its configuration file. There should be a wrapper.conf file located under the directory structure of the application containing the wrapper binary. If you would like to send me that on or off list, I can take a look at it and tell you what the Wrapper is being used to run. Cheers, Leif On Tue, Apr 28, 2009 at 4:27 AM, Weeks, John <Joh...@me...> wrote: > Hi, > > Programmers at our site are running the "wrapper" tool. Our security > scanner flagged this as a threat because it was able to use the "../../" > syntax to pull any random file (including the password file) off of the > server via HTTP. I am not JAVA-literate. Can anyone point me into the > right direction as far as how to configure wrapper to limit the directory > tree that it can see on this server? I know how to do this in Apache, but > wrapper appears to be running on its own TPC/IP port without using a web > server as a front end. > > -john- |
|
From: Weeks, J. <Joh...@me...> - 2009-04-27 19:27:47
|
Hi, Programmers at our site are running the "wrapper" tool. Our security scanner flagged this as a threat because it was able to use the "../../" syntax to pull any random file (including the password file) off of the server via HTTP. I am not JAVA-literate. Can anyone point me into the right direction as far as how to configure wrapper to limit the directory tree that it can see on this server? I know how to do this in Apache, but wrapper appears to be running on its own TPC/IP port without using a web server as a front end. -john- |
|
From: Roma <shm...@ya...> - 2009-04-26 21:08:04
|
Thank you, Leif! This works great :) 20.04.09, 12:43, "Leif Mortenson" <lei...@ta...>: > Roma, > You can pass parameters to your application the same as with other > Java Applications. |
|
From: Christian H. <ch...@aa...> - 2009-04-22 12:04:36
|
Hi all, i wanted to know if anybody knows a good way to run a j2ee application client (in glassfish) as a service using java service wrapper? I don't know if it is possible to use webstart apps with service wrapper. Nor if there is a different way to get your application client working without webstart (i.e. running it via command line). Thanks in advance for your input Christian |
|
From: Leif M. <lei...@ta...> - 2009-04-20 08:43:17
|
Roma, You can pass parameters to your application the same as with other Java Applications. Normally you would run it as "java -jar myjar.jar arg0 arg1 arg2" With the Wrapper, this would be: wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperJarApp wrapper.app.parameter.1=../lib/wrappertest.jar wrapper.app.parameter.2=arg0 wrapper.app.parameter.3=arg1 wrapper.app.parameter.4=arg2 If you want to set the first argument from the command line, then it would be done like this: wrapper.exe -c ..¥conf¥wrapper.conf wrapper.app.parameter.2=arg0 Note that this can only be used to install the service: wrapper.exe -i ..¥conf¥wrapper.conf wrapper.app.parameter.2=arg0 When the service is started and stopped, there is no way to specify other parameter values from the command line. You can do so however by creating a small included configuration file dynamically. Let me know exactly what you want to do and I might be able to help out further. Cheers, Leif On Sun, Apr 19, 2009 at 3:49 AM, Roma <shm...@ya...> wrote: > Hi! > > How can I pass parameters to my application? > I use WrapperJarApp to launch it as service.. > > Thank you! |
|
From: Roma <shm...@ya...> - 2009-04-18 18:50:09
|
Hi! How can I pass parameters to my application? I use WrapperJarApp to launch it as service.. Thank you! |
|
From: Leif M. <le...@ta...> - 2009-04-17 23:25:03
|
Christian, It is possible to run multiple instances of the Java Service Wrapper as services on the same machine, but each wrapper's configuration must have a unique service name and description. In addition, if the two services are running from the same directory, you will need to make sure that they each write to their own wrapper.log file. There are a couple ways of doing this that might work for you. 1) I have done things like this before by creating a shared wrapper-common.conf file which contains all of the common configurations. Then create a separate wrapper-app-N.conf file for each of your services, including the common configuration file: wrapper-app-N.conf: --- #include ../conf/wrapper-common.conf wrapper.logfile=../logs/wrapper-app-N.log wrapper.ntservice.name=app-N wrapper.ntservice.displayname=Application N --- 2) Another solution is to take advantage of the ability to set environment variables by setting properties, and the fact that any property can be set on the command line. Modify the following properties as follows: wrapper.logfile=../logs/wrapper-%APPN%.log wrapper.ntservice.name=app-%APPN% wrapper.ntservice.displayname=Application %APPN% Then when you launch the Wrapper, do so as follows: wrapper.exe -c ..¥conf¥wrapper.conf set.APPN=1 The service can be installed as follows: wrapper.exe -i ..¥conf¥wrapper.conf set.APPN=1 The above will be stored when the service is registered with the ServiceManager so it will work correctly when starting and stopping the service. You will need to specify the APPN value whenever you run the wrapper with any of its commands. Let me know how this works for you. Cheers, Leif On Fri, Apr 17, 2009 at 10:24 PM, Christian Hehtke <ch...@aa...> wrote: > Hi all, > > > > I would like to know what the best pratice for the following scenario is. > > > > I have an application which has to install system services at runtime, > depending on how much of the services are defined in configuration .These > system services will often call the same class in the same jar, but with > different parameters. > > Is there a way to accomplish that without copying the config files, etc? > > Thanks in advance > > > > Christian |
|
From: Christian H. <ch...@aa...> - 2009-04-17 13:51:34
|
Hi all, I would like to know what the best pratice for the following scenario is. I have an application which has to install system services at runtime, depending on how much of the services are defined in configuration .These system services will often call the same class in the same jar, but with different parameters. Is there a way to accomplish that without copying the config files, etc? Thanks in advance Christian |
|
From: Leif M. <lei...@ta...> - 2009-04-17 08:15:02
|
Andreas, One think that you have to be very careful of is to make sure that the JVM is never forced to swap any of its memory to disk. This is nothing related to the Wrapper. But Java gets VERY VERY VERY slow when its memory is being swapped. It is common for 1/1000 affect on performance. It may be possible that your new database is using a lot more memory and thus forcing the JVM to swap. Take a look at your task manager and make sure you have enough memory. I will see if there is any way that I can tell when this is happening to Java and warn the user about it in the log. Cheers, Leif On Fri, Apr 17, 2009 at 5:02 PM, Andreas Karlsson <and...@ya...> wrote: > > Hi Leif, > I've restarted it with the setting you suggested. > The problem shows up at any time between 7-10 days from last restart. > Often the application complains about low memory and performs garbage collection > prior to that. > I've been fiddling with the memory settings and now they should be the same for the > server-jvm-wrapper but the error still occurs. > I'll get back to you next week when it has restarted again. > brgds > Andreas > > --- Leif Mortenson <le...@ta...> wrote: > >> Andreas, >> Most likely the Java process is being starved of CPU and that is >> leading to the Wrapper thinking it is frozen. If that is the case >> then you can easily resolve the problem by setting the following >> property: >> wrapper.ping.timeout=120 >> (http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html) >> >> That will tell the Wrapper to allow the JVM to be frozen for 120 >> seconds before it is killed. The default is 30 seconds. >> >> However, your web site would be unresponsive during that period still. >> Most likely it is now for at least 30 seconds. Do the restarts >> happen at any particular time each week? Is there some large DB >> processing being done that is consuming all of the CPU? It may be >> necessary to move the Database over to another physical server to make >> sure your app server is not being affected by that processing. >> >> If you set the wrapper.debug=TRUE property and then reproduce this, I >> might be able to tell you a little more information about what is >> happening prior to the restart. I would only need the 3-5 minutes of >> time prior to the Wrapper timing out and killing the JVM. >> >> There have also been several bugs fixed since 3.0.5 which could affect >> this. Please review the release-notes: >> http://wrapper.tanukisoftware.org/doc/english/release-notes.html >> >> Cheers, >> Leif >> >> On Thu, Apr 16, 2009 at 5:55 PM, Andreas Karlsson >> <and...@ya...> wrote: >> > >> > Hi wrapper-folks! >> > I would love some hints and ideas on how to debug this problem and find a >> solution. >> > >> > The system is a >> > - windows server 2003 >> > - jettyserver >> > - java 1.4.1 >> > - wrapper 3.0.5 >> > >> > It has been running for years without any problems. But after some updates of >> the >> > data in the database where the web-content is stored and a recompile of the code >> it >> > started to produce these messages (pasted below). It happens approximately once >> > every week. >> > How can I debug this? >> > Is there a way to trigg a dump when it happens? >> > >> > >> > ERROR | wrapper | 2009/04/15 10:17:07 | JVM appears hung: Timed out waiting >> for >> > signal from JVM. >> > ERROR | wrapper | 2009/04/15 10:17:07 | Java Virtual Machine did not exit on >> > request, terminated >> > STATUS | wrapper | 2009/04/15 10:17:13 | Launching a JVM... >> > INFO | jvm 2 | 2009/04/15 10:17:14 | Wrapper (Version 3.0.5) >> > >> > brgds >> > Andreas |
|
From: Andreas K. <and...@ya...> - 2009-04-17 08:02:20
|
Hi Leif, I've restarted it with the setting you suggested. The problem shows up at any time between 7-10 days from last restart. Often the application complains about low memory and performs garbage collection prior to that. I've been fiddling with the memory settings and now they should be the same for the server-jvm-wrapper but the error still occurs. I'll get back to you next week when it has restarted again. brgds Andreas --- Leif Mortenson <le...@ta...> wrote: > Andreas, > Most likely the Java process is being starved of CPU and that is > leading to the Wrapper thinking it is frozen. If that is the case > then you can easily resolve the problem by setting the following > property: > wrapper.ping.timeout=120 > (http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html) > > That will tell the Wrapper to allow the JVM to be frozen for 120 > seconds before it is killed. The default is 30 seconds. > > However, your web site would be unresponsive during that period still. > Most likely it is now for at least 30 seconds. Do the restarts > happen at any particular time each week? Is there some large DB > processing being done that is consuming all of the CPU? It may be > necessary to move the Database over to another physical server to make > sure your app server is not being affected by that processing. > > If you set the wrapper.debug=TRUE property and then reproduce this, I > might be able to tell you a little more information about what is > happening prior to the restart. I would only need the 3-5 minutes of > time prior to the Wrapper timing out and killing the JVM. > > There have also been several bugs fixed since 3.0.5 which could affect > this. Please review the release-notes: > http://wrapper.tanukisoftware.org/doc/english/release-notes.html > > Cheers, > Leif > > On Thu, Apr 16, 2009 at 5:55 PM, Andreas Karlsson > <and...@ya...> wrote: > > > > Hi wrapper-folks! > > I would love some hints and ideas on how to debug this problem and find a > solution. > > > > The system is a > > - windows server 2003 > > - jettyserver > > - java 1.4.1 > > - wrapper 3.0.5 > > > > It has been running for years without any problems. But after some updates of > the > > data in the database where the web-content is stored and a recompile of the code > it > > started to produce these messages (pasted below). It happens approximately once > > every week. > > How can I debug this? > > Is there a way to trigg a dump when it happens? > > > > > > ERROR | wrapper | 2009/04/15 10:17:07 | JVM appears hung: Timed out waiting > for > > signal from JVM. > > ERROR | wrapper | 2009/04/15 10:17:07 | Java Virtual Machine did not exit on > > request, terminated > > STATUS | wrapper | 2009/04/15 10:17:13 | Launching a JVM... > > INFO | jvm 2 | 2009/04/15 10:17:14 | Wrapper (Version 3.0.5) > > > > brgds > > Andreas > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Leif M. <le...@ta...> - 2009-04-17 05:52:49
|
Andreas, Most likely the Java process is being starved of CPU and that is leading to the Wrapper thinking it is frozen. If that is the case then you can easily resolve the problem by setting the following property: wrapper.ping.timeout=120 (http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html) That will tell the Wrapper to allow the JVM to be frozen for 120 seconds before it is killed. The default is 30 seconds. However, your web site would be unresponsive during that period still. Most likely it is now for at least 30 seconds. Do the restarts happen at any particular time each week? Is there some large DB processing being done that is consuming all of the CPU? It may be necessary to move the Database over to another physical server to make sure your app server is not being affected by that processing. If you set the wrapper.debug=TRUE property and then reproduce this, I might be able to tell you a little more information about what is happening prior to the restart. I would only need the 3-5 minutes of time prior to the Wrapper timing out and killing the JVM. There have also been several bugs fixed since 3.0.5 which could affect this. Please review the release-notes: http://wrapper.tanukisoftware.org/doc/english/release-notes.html Cheers, Leif On Thu, Apr 16, 2009 at 5:55 PM, Andreas Karlsson <and...@ya...> wrote: > > Hi wrapper-folks! > I would love some hints and ideas on how to debug this problem and find a solution. > > The system is a > - windows server 2003 > - jettyserver > - java 1.4.1 > - wrapper 3.0.5 > > It has been running for years without any problems. But after some updates of the > data in the database where the web-content is stored and a recompile of the code it > started to produce these messages (pasted below). It happens approximately once > every week. > How can I debug this? > Is there a way to trigg a dump when it happens? > > > ERROR | wrapper | 2009/04/15 10:17:07 | JVM appears hung: Timed out waiting for > signal from JVM. > ERROR | wrapper | 2009/04/15 10:17:07 | Java Virtual Machine did not exit on > request, terminated > STATUS | wrapper | 2009/04/15 10:17:13 | Launching a JVM... > INFO | jvm 2 | 2009/04/15 10:17:14 | Wrapper (Version 3.0.5) > > brgds > Andreas |
|
From: Andreas K. <and...@ya...> - 2009-04-16 08:55:28
|
Hi wrapper-folks!
I would love some hints and ideas on how to debug this problem and find a solution.
The system is a
- windows server 2003
- jettyserver
- java 1.4.1
- wrapper 3.0.5
It has been running for years without any problems. But after some updates of the
data in the database where the web-content is stored and a recompile of the code it
started to produce these messages (pasted below). It happens approximately once
every week.
How can I debug this?
Is there a way to trigg a dump when it happens?
ERROR | wrapper | 2009/04/15 10:17:07 | JVM appears hung: Timed out waiting for
signal from JVM.
ERROR | wrapper | 2009/04/15 10:17:07 | Java Virtual Machine did not exit on
request, terminated
STATUS | wrapper | 2009/04/15 10:17:13 | Launching a JVM...
INFO | jvm 2 | 2009/04/15 10:17:14 | Wrapper (Version 3.0.5)
brgds
Andreas
|
|
From: Leif M. <lei...@ta...> - 2009-04-08 07:59:14
|
Isaiah, Problems like this are common with network applications across the open internet. I don't see anything here that is related specifically to the Wrapper. Are you concerned that the Wrapper might be related? Cheers, Leif On Wed, Apr 8, 2009 at 4:32 PM, Isaiah K Peram <isa...@in...> wrote: > > HI Guys , > > We are using Wrappers in our FTPManager application where in we transfer the > files from Our Server Systems to Mainframes machine located in Germany . > > We are Regularly facing this issue of Connection Reset , First i thought it > would be cos of network drop off > > Any help is much appreciated . > > The error is shown below : > > java.net.SocketException: Connection reset > at > java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code)) > at > java.io.BufferedInputStream.read1(BufferedInputStream.java(Compiled Code)) > at > java.io.BufferedInputStream.read(BufferedInputStream.java(Compiled Code)) > at > java.io.BufferedInputStream.fill(BufferedInputStream.java(Inlined Compiled > Code)) > at > java.io.BufferedInputStream.read(BufferedInputStream.java(Inlined Compiled > Code)) > at > org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java(Compiled > Code)) > at > org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java(Compiled > Code)) > at java.lang.Thread.run(Thread.java(Compiled Code)) > > Thanks and Regards , > > Isaiah Kumar P . |
|
From: Isaiah K P. <isa...@in...> - 2009-04-08 07:49:01
|
HI Guys ,
We are using Wrappers in our FTPManager application where in we transfer
the files from Our Server Systems to Mainframes machine located in Germany
.
We are Regularly facing this issue of Connection Reset , First i thought
it would be cos of network drop off
Any help is much appreciated .
The error is shown below :
java.net.SocketException: Connection reset
at
java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code))
at
java.io.BufferedInputStream.read1(BufferedInputStream.java(Compiled Code))
at
java.io.BufferedInputStream.read(BufferedInputStream.java(Compiled Code))
at
java.io.BufferedInputStream.fill(BufferedInputStream.java(Inlined Compiled
Code))
at
java.io.BufferedInputStream.read(BufferedInputStream.java(Inlined Compiled
Code))
at
org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java(Compiled
Code))
at
org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java(Compiled
Code))
at java.lang.Thread.run(Thread.java(Compiled Code))
Thanks and Regards ,
Isaiah Kumar P .
DCAup India ,
IBM India Pvt Ltd ,
Hitech City ,
Madhapur ,
Hyderabad - 82 .
Ph No : +9190027760
Desk No : +914066957239 ,
---------------------------------------------------------------------------
Do not fear going forward slowly; fear only to stand still.
---------------------------------------------------------------------------
|
|
From: Isaiah K P. <isa...@in...> - 2009-04-08 07:36:20
|
HI Guys ,
We are using Wrappers in our FTPManager application where in we transfer
the files from Our Server Systems to Mainframes machine located in Germany
.
We are Regularly facing this issue of Connection Reset , First i thought
it would be cos of network drop off
Any help is much appreciated .
The error is shown below :
java.net.SocketException: Connection reset
at
java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code))
at
java.io.BufferedInputStream.read1(BufferedInputStream.java(Compiled Code))
at
java.io.BufferedInputStream.read(BufferedInputStream.java(Compiled Code))
at
java.io.BufferedInputStream.fill(BufferedInputStream.java(Inlined Compiled
Code))
at
java.io.BufferedInputStream.read(BufferedInputStream.java(Inlined Compiled
Code))
at
org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java(Compiled
Code))
at
org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java(Compiled
Code))
at java.lang.Thread.run(Thread.java(Compiled Code))
Thanks and Regards ,
Isaiah Kumar P .
DCAup India ,
IBM India Pvt Ltd ,
Hitech City ,
Madhapur ,
Hyderabad - 82 .
Ph No : +9190027760
Desk No : +914066957239 ,
---------------------------------------------------------------------------
Do not fear going forward slowly; fear only to stand still.
---------------------------------------------------------------------------
|
|
From: Leif M. <lei...@ta...> - 2009-04-08 03:31:54
|
Juergen, I was not clear on this comment. You can easily use the SDK by pointing the Wrapper to that java installation. For example. Try the following in your wrapper.conf --- set.JAVA_HOME=C:\Sun\jdk1.6.0_10 wrapper.java.command=%JAVA_HOME%/bin/java --- The first property is a syntax that lets you set specific environment variables. I prefer to do something like the above because it lets you control precisely what JVM is used by your application even across multiple machines. If you rely on the PATH, then another administrator could inadvertently break your application by changing the PATH to point to a different JVM version. Cheers, Leif On Mon, Apr 6, 2009 at 10:07 PM, Hans-Juergen Schumacher <ju...@si...> wrote: > Leif, > > thx a lot. Finally the wrapper starts perfectly, however I really needed the > sdk instead of jre but this wont bother me much right now. > > Juergen > > Leif Mortenson wrote: > > Juergen, > Your wrapper.java.command appears to be: > wrapper.java.command=java > > Most likely java does not exist on the PATH in the environment where > the Wrapper is being run. > > Try setting it to one of the following: > wrapper.java.command=%JAVA_HOME%/bin/java > or > wrapper.java.command=/full/path/to/sdk/bin/java > > The first assumes that the JAVA_HOME environment variable is set. > > In the command that you sent, I notice that the M2_REPO, MULE_LIB, and > LD_LIBRARY_PATH environment variables are also all undefined. > > Cheers, > Leif > > > On Mon, Apr 6, 2009 at 7:45 PM, Hans-Juergen Schumacher > <ju...@si...> wrote: > > > Hello Leif, > > here is the output. Please let me know if you have any idea. > > Working directory set to: /home/tom_12/smscki/registration-mule/bin > --> Wrapper Started as Console > Using tick timer. > server listening on port 32000. > Classpath element, wrapper.java.classpath.2, does not exist: %MULE_LIB% > Command[0] : java > Command[1] : -Dmule.home=/home/tom_12/smscki/registration-mule > Command[2] : -Dmule.base=/home/tom_12/smscki/registration-mule > Command[3] : -Dm2.repo="%M2_REPO%" > Command[4] : > -Dmule.bootstrap.library.download.description.1=javax.activation.DataSource,/javax/activation/activation/1.1,activation-1.1.jar > Command[5] : > -Dmule.bootstrap.library.download.description.2=javax.mail.Message,/javax/mail/mail/1.4,mail-1.4.jar > Command[6] : > -Djava.endorsed.dirs=/home/tom_12/smscki/registration-mule/lib/endorsed > Command[7] : -Xmx512m > Command[8] : > -Djava.library.path=%LD_LIBRARY_PATH%:/home/tom_12/smscki/registration-mule/lib/boot > Command[9] : -classpath > Command[10] : > /home/tom_12/smscki/registration-mule/bin/../conf:%MULE_LIB%:/home/tom_12/smscki/registration-mule/lib/boot/wrapper-3.2.3.jar:/home/tom_12/smscki/registration-mule/lib/boot/mule-module-boot-1.4.4.jar:/home/tom_12/smscki/registration-mule/lib/boot/commons-cli-1.0.jar > Command[11] : -Dwrapper.key=iXleguo6tkdqhlTT > Command[12] : -Dwrapper.port=32000 > Command[13] : -Dwrapper.jvm.port.min=31000 > Command[14] : -Dwrapper.jvm.port.max=31999 > Command[15] : -Dwrapper.debug=TRUE > Command[16] : -Dwrapper.pid=28454 > Command[17] : -Dwrapper.version=3.2.3 > Command[18] : -Dwrapper.native_library=wrapper > Command[19] : -Dwrapper.cpu.timeout=10 > Command[20] : -Dwrapper.jvmid=1 > Command[21] : org.mule.modules.boot.MuleBootstrap > Command[22] : console0 > Launching a JVM... > Signal trapped. Details: > signal number=17 (SIGCHLD), source="unknown" > Received SIGCHLD, checking JVM process status. > JVM process exited with a code of 1, setting the wrapper exit code to 1. > JVM exited while loading the application. > Unable to start JVM: No such file or directory (2) > JVM was only running for 0 seconds leading to a failed restart count of 1. > Waiting 5 seconds before launching another JVM. > > > Thx a lot, > > juergen > > Leif Mortenson wrote: > > Juergen, > Try setting the wrapper.java.command.loglevel=INFO property. This > will cause the Wrapper to log the full java command line. Most > likely java binary is not being found correctly. > > If that does not make the problem obvious. Please set the > wrapper.debug=TRUE property and reply with the resulting wrapper.log > file attached. I should be able to point out the problem for you > then. > > Cheers, > Leif > > On Sat, Apr 4, 2009 at 1:01 AM, Hans-Juergen Schumacher > <ju...@si...> wrote: > > > Hi, > I always get a failure when I try to start the wrapper: > > wrapper | Unable to start JVM: No such file or directory > > I have no idea what file or directory he is looking for. I think > something with permissions maybe...any help is appreciated. > > Thx > juergen |
|
From: Leif M. <le...@ta...> - 2009-04-08 03:27:44
|
Rob, Agreed. I have added some advice messages when the Wrapper fails to launch the JVM on Windows or UNIX platforms. This was actually a little difficult on UNIX because the logging needs to take place after the Wrapper has been forked to launch the JVM. Anyway. This will be in the upcoming 3.3.4 release. Cheers, Leif On Mon, Apr 6, 2009 at 9:08 PM, Leland, Robert <rob...@io...> wrote: > Leif, > > > In the short time I have been a member of this list I have seen similar problems of just using 'java' instead of a full path. Maybe this should be a warning in the log files, if this isn't already. > > -Rob > > ___________________________________ > Robert Leland INTEGRITYOne Partners > P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 > F: (703) 476-7405 Reston, VA 20191 > rob...@io... > > BUSINESS CONSULTING | TECHNOLOGY | INNOVATION R&D > > ________________________________ > > From: Leif Mortenson [mailto:lei...@ta...] > Sent: Mon 4/6/2009 8:05 AM > To: wra...@li... > Subject: Re: [Wrapper-user] wrapper dont start > > > > Juergen, > Your wrapper.java.command appears to be: > wrapper.java.command=java > > Most likely java does not exist on the PATH in the environment where > the Wrapper is being run. > > Try setting it to one of the following: > wrapper.java.command=%JAVA_HOME%/bin/java > or > wrapper.java.command=/full/path/to/sdk/bin/java > > The first assumes that the JAVA_HOME environment variable is set. > > In the command that you sent, I notice that the M2_REPO, MULE_LIB, and > LD_LIBRARY_PATH environment variables are also all undefined. > > Cheers, > Leif > > > On Mon, Apr 6, 2009 at 7:45 PM, Hans-Juergen Schumacher > <ju...@si...> wrote: >> Hello Leif, >> >> here is the output. Please let me know if you have any idea. >> >> Working directory set to: /home/tom_12/smscki/registration-mule/bin >> --> Wrapper Started as Console >> Using tick timer. >> server listening on port 32000. >> Classpath element, wrapper.java.classpath.2, does not exist: %MULE_LIB% >> Command[0] : java >> Command[1] : -Dmule.home=/home/tom_12/smscki/registration-mule >> Command[2] : -Dmule.base=/home/tom_12/smscki/registration-mule >> Command[3] : -Dm2.repo="%M2_REPO%" >> Command[4] : >> -Dmule.bootstrap.library.download.description.1=javax.activation.DataSource,/javax/activation/activation/1.1,activation-1.1.jar >> Command[5] : >> -Dmule.bootstrap.library.download.description.2=javax.mail.Message,/javax/mail/mail/1.4,mail-1.4.jar >> Command[6] : >> -Djava.endorsed.dirs=/home/tom_12/smscki/registration-mule/lib/endorsed >> Command[7] : -Xmx512m >> Command[8] : >> -Djava.library.path=%LD_LIBRARY_PATH%:/home/tom_12/smscki/registration-mule/lib/boot >> Command[9] : -classpath >> Command[10] : >> /home/tom_12/smscki/registration-mule/bin/../conf:%MULE_LIB%:/home/tom_12/smscki/registration-mule/lib/boot/wrapper-3.2.3.jar:/home/tom_12/smscki/registration-mule/lib/boot/mule-module-boot-1.4.4.jar:/home/tom_12/smscki/registration-mule/lib/boot/commons-cli-1.0.jar >> Command[11] : -Dwrapper.key=iXleguo6tkdqhlTT >> Command[12] : -Dwrapper.port=32000 >> Command[13] : -Dwrapper.jvm.port.min=31000 >> Command[14] : -Dwrapper.jvm.port.max=31999 >> Command[15] : -Dwrapper.debug=TRUE >> Command[16] : -Dwrapper.pid=28454 >> Command[17] : -Dwrapper.version=3.2.3 >> Command[18] : -Dwrapper.native_library=wrapper >> Command[19] : -Dwrapper.cpu.timeout=10 >> Command[20] : -Dwrapper.jvmid=1 >> Command[21] : org.mule.modules.boot.MuleBootstrap >> Command[22] : console0 >> Launching a JVM... >> Signal trapped. Details: >> signal number=17 (SIGCHLD), source="unknown" >> Received SIGCHLD, checking JVM process status. >> JVM process exited with a code of 1, setting the wrapper exit code to 1. >> JVM exited while loading the application. >> Unable to start JVM: No such file or directory (2) >> JVM was only running for 0 seconds leading to a failed restart count of 1. >> Waiting 5 seconds before launching another JVM. >> >> >> Thx a lot, >> >> juergen >> >> Leif Mortenson wrote: >> >> Juergen, >> Try setting the wrapper.java.command.loglevel=INFO property. This >> will cause the Wrapper to log the full java command line. Most >> likely java binary is not being found correctly. >> >> If that does not make the problem obvious. Please set the >> wrapper.debug=TRUE property and reply with the resulting wrapper.log >> file attached. I should be able to point out the problem for you >> then. >> >> Cheers, >> Leif >> >> On Sat, Apr 4, 2009 at 1:01 AM, Hans-Juergen Schumacher >> <ju...@si...> wrote: >> >> >> Hi, >> I always get a failure when I try to start the wrapper: >> >> wrapper | Unable to start JVM: No such file or directory >> >> I have no idea what file or directory he is looking for. I think >> something with permissions maybe...any help is appreciated. >> >> Thx >> juergen |
|
From: Hans-Juergen S. <ju...@si...> - 2009-04-06 13:07:39
|
Leif, thx a lot. Finally the wrapper starts perfectly, however I really needed the sdk instead of jre but this wont bother me much right now. Juergen Leif Mortenson wrote: > Juergen, > Your wrapper.java.command appears to be: > wrapper.java.command=java > > Most likely java does not exist on the PATH in the environment where > the Wrapper is being run. > > Try setting it to one of the following: > wrapper.java.command=%JAVA_HOME%/bin/java > or > wrapper.java.command=/full/path/to/sdk/bin/java > > The first assumes that the JAVA_HOME environment variable is set. > > In the command that you sent, I notice that the M2_REPO, MULE_LIB, and > LD_LIBRARY_PATH environment variables are also all undefined. > > Cheers, > Leif > > > On Mon, Apr 6, 2009 at 7:45 PM, Hans-Juergen Schumacher > <ju...@si...> wrote: > >> Hello Leif, >> >> here is the output. Please let me know if you have any idea. >> >> Working directory set to: /home/tom_12/smscki/registration-mule/bin >> --> Wrapper Started as Console >> Using tick timer. >> server listening on port 32000. >> Classpath element, wrapper.java.classpath.2, does not exist: %MULE_LIB% >> Command[0] : java >> Command[1] : -Dmule.home=/home/tom_12/smscki/registration-mule >> Command[2] : -Dmule.base=/home/tom_12/smscki/registration-mule >> Command[3] : -Dm2.repo="%M2_REPO%" >> Command[4] : >> -Dmule.bootstrap.library.download.description.1=javax.activation.DataSource,/javax/activation/activation/1.1,activation-1.1.jar >> Command[5] : >> -Dmule.bootstrap.library.download.description.2=javax.mail.Message,/javax/mail/mail/1.4,mail-1.4.jar >> Command[6] : >> -Djava.endorsed.dirs=/home/tom_12/smscki/registration-mule/lib/endorsed >> Command[7] : -Xmx512m >> Command[8] : >> -Djava.library.path=%LD_LIBRARY_PATH%:/home/tom_12/smscki/registration-mule/lib/boot >> Command[9] : -classpath >> Command[10] : >> /home/tom_12/smscki/registration-mule/bin/../conf:%MULE_LIB%:/home/tom_12/smscki/registration-mule/lib/boot/wrapper-3.2.3.jar:/home/tom_12/smscki/registration-mule/lib/boot/mule-module-boot-1.4.4.jar:/home/tom_12/smscki/registration-mule/lib/boot/commons-cli-1.0.jar >> Command[11] : -Dwrapper.key=iXleguo6tkdqhlTT >> Command[12] : -Dwrapper.port=32000 >> Command[13] : -Dwrapper.jvm.port.min=31000 >> Command[14] : -Dwrapper.jvm.port.max=31999 >> Command[15] : -Dwrapper.debug=TRUE >> Command[16] : -Dwrapper.pid=28454 >> Command[17] : -Dwrapper.version=3.2.3 >> Command[18] : -Dwrapper.native_library=wrapper >> Command[19] : -Dwrapper.cpu.timeout=10 >> Command[20] : -Dwrapper.jvmid=1 >> Command[21] : org.mule.modules.boot.MuleBootstrap >> Command[22] : console0 >> Launching a JVM... >> Signal trapped. Details: >> signal number=17 (SIGCHLD), source="unknown" >> Received SIGCHLD, checking JVM process status. >> JVM process exited with a code of 1, setting the wrapper exit code to 1. >> JVM exited while loading the application. >> Unable to start JVM: No such file or directory (2) >> JVM was only running for 0 seconds leading to a failed restart count of 1. >> Waiting 5 seconds before launching another JVM. >> >> >> Thx a lot, >> >> juergen >> >> Leif Mortenson wrote: >> >> Juergen, >> Try setting the wrapper.java.command.loglevel=INFO property. This >> will cause the Wrapper to log the full java command line. Most >> likely java binary is not being found correctly. >> >> If that does not make the problem obvious. Please set the >> wrapper.debug=TRUE property and reply with the resulting wrapper.log >> file attached. I should be able to point out the problem for you >> then. >> >> Cheers, >> Leif >> >> On Sat, Apr 4, 2009 at 1:01 AM, Hans-Juergen Schumacher >> <ju...@si...> wrote: >> >> >> Hi, >> I always get a failure when I try to start the wrapper: >> >> wrapper | Unable to start JVM: No such file or directory >> >> I have no idea what file or directory he is looking for. I think >> something with permissions maybe...any help is appreciated. >> >> Thx >> juergen >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Leland, R. <rob...@io...> - 2009-04-06 12:12:04
|
Leif, In the short time I have been a member of this list I have seen similar problems of just using 'java' instead of a full path. Maybe this should be a warning in the log files, if this isn't already. -Rob ___________________________________ Robert Leland INTEGRITYOne Partners P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 rob...@io... BUSINESS CONSULTING | TECHNOLOGY | INNOVATION R&D ________________________________ From: Leif Mortenson [mailto:lei...@ta...] Sent: Mon 4/6/2009 8:05 AM To: wra...@li... Subject: Re: [Wrapper-user] wrapper dont start Juergen, Your wrapper.java.command appears to be: wrapper.java.command=java Most likely java does not exist on the PATH in the environment where the Wrapper is being run. Try setting it to one of the following: wrapper.java.command=%JAVA_HOME%/bin/java or wrapper.java.command=/full/path/to/sdk/bin/java The first assumes that the JAVA_HOME environment variable is set. In the command that you sent, I notice that the M2_REPO, MULE_LIB, and LD_LIBRARY_PATH environment variables are also all undefined. Cheers, Leif On Mon, Apr 6, 2009 at 7:45 PM, Hans-Juergen Schumacher <ju...@si...> wrote: > Hello Leif, > > here is the output. Please let me know if you have any idea. > > Working directory set to: /home/tom_12/smscki/registration-mule/bin > --> Wrapper Started as Console > Using tick timer. > server listening on port 32000. > Classpath element, wrapper.java.classpath.2, does not exist: %MULE_LIB% > Command[0] : java > Command[1] : -Dmule.home=/home/tom_12/smscki/registration-mule > Command[2] : -Dmule.base=/home/tom_12/smscki/registration-mule > Command[3] : -Dm2.repo="%M2_REPO%" > Command[4] : > -Dmule.bootstrap.library.download.description.1=javax.activation.DataSource,/javax/activation/activation/1.1,activation-1.1.jar > Command[5] : > -Dmule.bootstrap.library.download.description.2=javax.mail.Message,/javax/mail/mail/1.4,mail-1.4.jar > Command[6] : > -Djava.endorsed.dirs=/home/tom_12/smscki/registration-mule/lib/endorsed > Command[7] : -Xmx512m > Command[8] : > -Djava.library.path=%LD_LIBRARY_PATH%:/home/tom_12/smscki/registration-mule/lib/boot > Command[9] : -classpath > Command[10] : > /home/tom_12/smscki/registration-mule/bin/../conf:%MULE_LIB%:/home/tom_12/smscki/registration-mule/lib/boot/wrapper-3.2.3.jar:/home/tom_12/smscki/registration-mule/lib/boot/mule-module-boot-1.4.4.jar:/home/tom_12/smscki/registration-mule/lib/boot/commons-cli-1.0.jar > Command[11] : -Dwrapper.key=iXleguo6tkdqhlTT > Command[12] : -Dwrapper.port=32000 > Command[13] : -Dwrapper.jvm.port.min=31000 > Command[14] : -Dwrapper.jvm.port.max=31999 > Command[15] : -Dwrapper.debug=TRUE > Command[16] : -Dwrapper.pid=28454 > Command[17] : -Dwrapper.version=3.2.3 > Command[18] : -Dwrapper.native_library=wrapper > Command[19] : -Dwrapper.cpu.timeout=10 > Command[20] : -Dwrapper.jvmid=1 > Command[21] : org.mule.modules.boot.MuleBootstrap > Command[22] : console0 > Launching a JVM... > Signal trapped. Details: > signal number=17 (SIGCHLD), source="unknown" > Received SIGCHLD, checking JVM process status. > JVM process exited with a code of 1, setting the wrapper exit code to 1. > JVM exited while loading the application. > Unable to start JVM: No such file or directory (2) > JVM was only running for 0 seconds leading to a failed restart count of 1. > Waiting 5 seconds before launching another JVM. > > > Thx a lot, > > juergen > > Leif Mortenson wrote: > > Juergen, > Try setting the wrapper.java.command.loglevel=INFO property. This > will cause the Wrapper to log the full java command line. Most > likely java binary is not being found correctly. > > If that does not make the problem obvious. Please set the > wrapper.debug=TRUE property and reply with the resulting wrapper.log > file attached. I should be able to point out the problem for you > then. > > Cheers, > Leif > > On Sat, Apr 4, 2009 at 1:01 AM, Hans-Juergen Schumacher > <ju...@si...> wrote: > > > Hi, > I always get a failure when I try to start the wrapper: > > wrapper | Unable to start JVM: No such file or directory > > I have no idea what file or directory he is looking for. I think > something with permissions maybe...any help is appreciated. > > Thx > juergen ------------------------------------------------------------------------------ _______________________________________________ Wrapper-user mailing list Wra...@li... https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Leif M. <lei...@ta...> - 2009-04-06 12:05:41
|
Juergen, Your wrapper.java.command appears to be: wrapper.java.command=java Most likely java does not exist on the PATH in the environment where the Wrapper is being run. Try setting it to one of the following: wrapper.java.command=%JAVA_HOME%/bin/java or wrapper.java.command=/full/path/to/sdk/bin/java The first assumes that the JAVA_HOME environment variable is set. In the command that you sent, I notice that the M2_REPO, MULE_LIB, and LD_LIBRARY_PATH environment variables are also all undefined. Cheers, Leif On Mon, Apr 6, 2009 at 7:45 PM, Hans-Juergen Schumacher <ju...@si...> wrote: > Hello Leif, > > here is the output. Please let me know if you have any idea. > > Working directory set to: /home/tom_12/smscki/registration-mule/bin > --> Wrapper Started as Console > Using tick timer. > server listening on port 32000. > Classpath element, wrapper.java.classpath.2, does not exist: %MULE_LIB% > Command[0] : java > Command[1] : -Dmule.home=/home/tom_12/smscki/registration-mule > Command[2] : -Dmule.base=/home/tom_12/smscki/registration-mule > Command[3] : -Dm2.repo="%M2_REPO%" > Command[4] : > -Dmule.bootstrap.library.download.description.1=javax.activation.DataSource,/javax/activation/activation/1.1,activation-1.1.jar > Command[5] : > -Dmule.bootstrap.library.download.description.2=javax.mail.Message,/javax/mail/mail/1.4,mail-1.4.jar > Command[6] : > -Djava.endorsed.dirs=/home/tom_12/smscki/registration-mule/lib/endorsed > Command[7] : -Xmx512m > Command[8] : > -Djava.library.path=%LD_LIBRARY_PATH%:/home/tom_12/smscki/registration-mule/lib/boot > Command[9] : -classpath > Command[10] : > /home/tom_12/smscki/registration-mule/bin/../conf:%MULE_LIB%:/home/tom_12/smscki/registration-mule/lib/boot/wrapper-3.2.3.jar:/home/tom_12/smscki/registration-mule/lib/boot/mule-module-boot-1.4.4.jar:/home/tom_12/smscki/registration-mule/lib/boot/commons-cli-1.0.jar > Command[11] : -Dwrapper.key=iXleguo6tkdqhlTT > Command[12] : -Dwrapper.port=32000 > Command[13] : -Dwrapper.jvm.port.min=31000 > Command[14] : -Dwrapper.jvm.port.max=31999 > Command[15] : -Dwrapper.debug=TRUE > Command[16] : -Dwrapper.pid=28454 > Command[17] : -Dwrapper.version=3.2.3 > Command[18] : -Dwrapper.native_library=wrapper > Command[19] : -Dwrapper.cpu.timeout=10 > Command[20] : -Dwrapper.jvmid=1 > Command[21] : org.mule.modules.boot.MuleBootstrap > Command[22] : console0 > Launching a JVM... > Signal trapped. Details: > signal number=17 (SIGCHLD), source="unknown" > Received SIGCHLD, checking JVM process status. > JVM process exited with a code of 1, setting the wrapper exit code to 1. > JVM exited while loading the application. > Unable to start JVM: No such file or directory (2) > JVM was only running for 0 seconds leading to a failed restart count of 1. > Waiting 5 seconds before launching another JVM. > > > Thx a lot, > > juergen > > Leif Mortenson wrote: > > Juergen, > Try setting the wrapper.java.command.loglevel=INFO property. This > will cause the Wrapper to log the full java command line. Most > likely java binary is not being found correctly. > > If that does not make the problem obvious. Please set the > wrapper.debug=TRUE property and reply with the resulting wrapper.log > file attached. I should be able to point out the problem for you > then. > > Cheers, > Leif > > On Sat, Apr 4, 2009 at 1:01 AM, Hans-Juergen Schumacher > <ju...@si...> wrote: > > > Hi, > I always get a failure when I try to start the wrapper: > > wrapper | Unable to start JVM: No such file or directory > > I have no idea what file or directory he is looking for. I think > something with permissions maybe...any help is appreciated. > > Thx > juergen |
|
From: Hans-Juergen S. <ju...@si...> - 2009-04-06 10:45:41
|
Hello Leif, here is the output. Please let me know if you have any idea. Working directory set to: /home/tom_12/smscki/registration-mule/bin --> Wrapper Started as Console Using tick timer. server listening on port 32000. Classpath element, wrapper.java.classpath.2, does not exist: %MULE_LIB% Command[0] : java Command[1] : -Dmule.home=/home/tom_12/smscki/registration-mule Command[2] : -Dmule.base=/home/tom_12/smscki/registration-mule Command[3] : -Dm2.repo="%M2_REPO%" Command[4] : -Dmule.bootstrap.library.download.description.1=javax.activation.DataSource,/javax/activation/activation/1.1,activation-1.1.jar Command[5] : -Dmule.bootstrap.library.download.description.2=javax.mail.Message,/javax/mail/mail/1.4,mail-1.4.jar Command[6] : -Djava.endorsed.dirs=/home/tom_12/smscki/registration-mule/lib/endorsed Command[7] : -Xmx512m Command[8] : -Djava.library.path=%LD_LIBRARY_PATH%:/home/tom_12/smscki/registration-mule/lib/boot Command[9] : -classpath Command[10] : /home/tom_12/smscki/registration-mule/bin/../conf:%MULE_LIB%:/home/tom_12/smscki/registration-mule/lib/boot/wrapper-3.2.3.jar:/home/tom_12/smscki/registration-mule/lib/boot/mule-module-boot-1.4.4.jar:/home/tom_12/smscki/registration-mule/lib/boot/commons-cli-1.0.jar Command[11] : -Dwrapper.key=iXleguo6tkdqhlTT Command[12] : -Dwrapper.port=32000 Command[13] : -Dwrapper.jvm.port.min=31000 Command[14] : -Dwrapper.jvm.port.max=31999 Command[15] : -Dwrapper.debug=TRUE Command[16] : -Dwrapper.pid=28454 Command[17] : -Dwrapper.version=3.2.3 Command[18] : -Dwrapper.native_library=wrapper Command[19] : -Dwrapper.cpu.timeout=10 Command[20] : -Dwrapper.jvmid=1 Command[21] : org.mule.modules.boot.MuleBootstrap Command[22] : console0 Launching a JVM... Signal trapped. Details: signal number=17 (SIGCHLD), source="unknown" Received SIGCHLD, checking JVM process status. JVM process exited with a code of 1, setting the wrapper exit code to 1. JVM exited while loading the application. Unable to start JVM: No such file or directory (2) JVM was only running for 0 seconds leading to a failed restart count of 1. Waiting 5 seconds before launching another JVM. Thx a lot, juergen Leif Mortenson wrote: > Juergen, > Try setting the wrapper.java.command.loglevel=INFO property. This > will cause the Wrapper to log the full java command line. Most > likely java binary is not being found correctly. > > If that does not make the problem obvious. Please set the > wrapper.debug=TRUE property and reply with the resulting wrapper.log > file attached. I should be able to point out the problem for you > then. > > Cheers, > Leif > > On Sat, Apr 4, 2009 at 1:01 AM, Hans-Juergen Schumacher > <ju...@si...> wrote: > >> Hi, >> I always get a failure when I try to start the wrapper: >> >> wrapper | Unable to start JVM: No such file or directory >> >> I have no idea what file or directory he is looking for. I think >> something with permissions maybe...any help is appreciated. >> >> Thx >> juergen >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Leif M. <lei...@ta...> - 2009-04-03 16:37:34
|
Juergen, Try setting the wrapper.java.command.loglevel=INFO property. This will cause the Wrapper to log the full java command line. Most likely java binary is not being found correctly. If that does not make the problem obvious. Please set the wrapper.debug=TRUE property and reply with the resulting wrapper.log file attached. I should be able to point out the problem for you then. Cheers, Leif On Sat, Apr 4, 2009 at 1:01 AM, Hans-Juergen Schumacher <ju...@si...> wrote: > Hi, > I always get a failure when I try to start the wrapper: > > wrapper | Unable to start JVM: No such file or directory > > I have no idea what file or directory he is looking for. I think > something with permissions maybe...any help is appreciated. > > Thx > juergen |
|
From: Hans-Juergen S. <ju...@si...> - 2009-04-03 16:28:55
|
Hi, I always get a failure when I try to start the wrapper: wrapper | Unable to start JVM: No such file or directory I have no idea what file or directory he is looking for. I think something with permissions maybe...any help is appreciated. Thx juergen |
|
From: Leif M. <lei...@ta...> - 2009-04-03 14:36:54
|
Thomas, Yes, the follow two properties can be used to extend the shutdown timeout: http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html Most likely, the second property is the one that you will want to extend. Let me know if you have any questions about your particular situation. Cheers, Leif On Fri, Apr 3, 2009 at 10:19 PM, Thomas Silveria <Tho...@ra...> wrote: > Hi; > Is there a way to increase the allocated time to stop the JBoss service > before the service control manager kills the process? > Thanks: > Tom |