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: Tim L. <tim...@gm...> - 2014-09-09 09:40:39
|
The leak occurs in 3.5.25 and earlier (64-bit), running on an linux machine (linux kernel 3.2.30-49.59). It is located in the #ifdef UNICODE block of the method: the buffer used in the WIN32 code could also be used in the UNICODE block. I am not sure this is the root cause of the problems we are seeing. I wrote a small test program which used the Java logging framework and is continuously logging a string with some unicode characters in it to reproduce the problem. That is also creating memory issues with the wrapper (3.5.25). I am currently suspecting locale/glibc problems due to security updates. I'll keep you posted if the root cause is in the service wrapper. Regards, Tim On Tue, Sep 9, 2014 at 11:17 AM, Leif Mortenson < lei...@ta...> wrote: > Tim, > I wanted to follow up as well. The getLastErrorText method is known to > have a small leak, but it is not normally called repeatedly. > Where it is we are specifically freeing the returned string. > > What is the version you are seeing the leak in? Is it something that you > have been able to reproduce? > There have been some other leaks fixed over time: > http://wrapper.tanukisoftware.com/doc/english/release-notes.html > > Cheers, > Leif > > > On Tue, Sep 9, 2014 at 4:34 PM, Alexandre Klein < > ale...@ta...> wrote: > >> Tim, >> >> Thank you for your email. >> We are aware of this issue with getLastErrorText() and it is in our bug >> tracking system. >> >> We will fix it in a future version of the Java Service Wrapper. >> >> If you see any other problem in our code, please let us know. We really >> want to improve the Wrapper and deliver a great product to our users. >> >> Regards, >> Alexandre Klein >> >> On Fri, Sep 5, 2014 at 9:37 PM, Tim Lammens <tim...@gm...> >> wrote: >> >>> Hi, >>> >>> We are using your wrapper and sometimes the wrapper itself goes out of >>> memory. >>> It seems when the method getLastErrorText() in the C code of the wrapper >>> is called, the memory allocated with malloc is not being freed afterwards. >>> Is this possible or did I miss something? >>> >>> Regards, >>> Tim >>> >> > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce. > Perforce version control. Predictably reliable. > > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Leif M. <lei...@ta...> - 2014-09-09 09:17:36
|
Tim, I wanted to follow up as well. The getLastErrorText method is known to have a small leak, but it is not normally called repeatedly. Where it is we are specifically freeing the returned string. What is the version you are seeing the leak in? Is it something that you have been able to reproduce? There have been some other leaks fixed over time: http://wrapper.tanukisoftware.com/doc/english/release-notes.html Cheers, Leif On Tue, Sep 9, 2014 at 4:34 PM, Alexandre Klein < ale...@ta...> wrote: > Tim, > > Thank you for your email. > We are aware of this issue with getLastErrorText() and it is in our bug > tracking system. > > We will fix it in a future version of the Java Service Wrapper. > > If you see any other problem in our code, please let us know. We really > want to improve the Wrapper and deliver a great product to our users. > > Regards, > Alexandre Klein > > On Fri, Sep 5, 2014 at 9:37 PM, Tim Lammens <tim...@gm...> wrote: > >> Hi, >> >> We are using your wrapper and sometimes the wrapper itself goes out of >> memory. >> It seems when the method getLastErrorText() in the C code of the wrapper >> is called, the memory allocated with malloc is not being freed afterwards. >> Is this possible or did I miss something? >> >> Regards, >> Tim >> > |
|
From: Alexandre K. <ale...@ta...> - 2014-09-09 08:05:15
|
Tim, Thank you for your email. We are aware of this issue with getLastErrorText() and it is in our bug tracking system. We will fix it in a future version of the Java Service Wrapper. If you see any other problem in our code, please let us know. We really want to improve the Wrapper and deliver a great product to our users. Regards, Alexandre Klein Alexandre Klein Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel: +81-3-3878-3211 Fax: +81-3-3878-0313 http://www.tanukisoftware.com On Fri, Sep 5, 2014 at 9:37 PM, Tim Lammens <tim...@gm...> wrote: > Hi, > > We are using your wrapper and sometimes the wrapper itself goes out of > memory. > It seems when the method getLastErrorText() in the C code of the wrapper > is called, the memory allocated with malloc is not being freed afterwards. > Is this possible or did I miss something? > > Regards, > Tim > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Tim L. <tim...@gm...> - 2014-09-05 12:37:40
|
Hi, We are using your wrapper and sometimes the wrapper itself goes out of memory. It seems when the method getLastErrorText() in the C code of the wrapper is called, the memory allocated with malloc is not being freed afterwards. Is this possible or did I miss something? Regards, Tim |
|
From: Vasco P. da S. <vp...@cd...> - 2014-09-04 08:51:24
|
Hi, Frequently the Windows services (running wrapper) are stopping with the Fatal Error message "unable to bind listener to any port in the range 32000-32999. (An attempt was made to access a socket in a way forbidden by its access permissions. (0x271d))". 40 services are running under Local System account and presented very few of these errors, other 40 services were running under a local user account with Admin permissions and stopped every night (off peak hours) . I did the following changes: * All services are now running under Local System account; * I have set the wrapper port min-max to: 45000 - 50000 (for the failing services, they use a separate conf file). I continue to get the same errors but not that frequently, but now the majority of the errors are from the 40 services that were originally running the Local System account. Have anyone experienced the same? System details: * OS - Windows 2012 * Java - 7.0_40 * Wrapper - 3.4.1 64 bit VPS |
|
From: Leif M. <lei...@ta...> - 2014-09-02 00:53:18
|
Lin, Thank you for the update. I am glad you got it working. I am curious what it was about the jar that was causing java 6 to fail to open it. If it was problem with the class being compiled for Java 7 (which is too new) then that would have been a different exception. We will try to look into this on this end as I don't like the way that error was misleading. But I would appreciate it if you have any ideas from what you found. Cheers, Leif On Tue, Sep 2, 2014 at 7:40 AM, Lin Zhao <li...@ex...> wrote: > Leif, > > Thanks for the reply. We already had it figured out. It's the java > version. My jar is built with sbt, and somehow the java 6 jvm can't find > the main class. Once I ensure the right java 7 JAVA_HOME it works. > On Sep 1, 2014 12:58 AM, "Leif Mortenson" < > lei...@ta...> wrote: > >> Lin, >> I am sorry for the very slow reply. We somehow missed that this mail was >> stuck in moderation. >> >> I think this is a problem with your working directory. Remember that >> when the Wrapper runs, it ALWAYS forces the current working directory to be >> the location of the wrapper binary. >> This is done so that the Wrapper runs consistently regardless of how the >> Wrapper is launched. >> In your case, when running with the Wrapper, the working directory is: >> /Users/lin/git/exabeam/martini/java-wrapper/bin >> >> I am not 100% sure what it is when you are running directly with your >> command line. >> In both cases, your classpath looks like this: >> ../lib/martini.jar:../lib/wrapper.jar >> >> In the case of running with the Wrapper, this would mean that these files >> are both located in the following directory: >> /Users/lin/git/exabeam/martini/java-wrapper/lib >> >> A couple things that are confusing to me: >> >> 1) If the jar files had not been found, you would be seeing a message >> like the following in the logs just before the JVM is launched: >> DEBUG | wrapper | 2014/09/01 16:02:40.255 | | Classpath >> element, wrapper.java.classpath.3, does not exist: ../lib/foo.jar >> DEBUG | wrapper | 2014/09/01 16:02:40.255 | | Classpath >> element, wrapper.java.classpath.4, does not exist: ../xxx/bar.jar >> The lack of these messages in the log makes it look like both files exist >> >> 2) How are you launching the Wrapper? Is this on system startup? The >> working directory of the parent that launched the Wrapper was the root >> directory: >> DEBUG | wrapper | 2014/08/18 22:06:42 | P--W- | WRAPPER_INIT_DIR=/ >> This should not matter as the working directory was correctly changed to >> the location of the Wrapper binary: >> DEBUG | wrapper | 2014/08/18 22:06:42 | ---W- | >> WRAPPER_WORKING_DIR=/Users/lin/git/exabeam/martini/java-wrapper/bin >> >> In both cases, the WrapperSimpleApp class is being located and loaded >> correctly. That class simply locates the "com.exabeam.martini.Martini" >> class by name in the same ClassLoader without doing anything special. >> >> If none of these hints help, would it be possible to get a tar of your >> application sent to su...@ta...? We should only need the >> martini.jar to be able to see if it locates your main class. But I am also >> interested in seeing the relative location of files. >> >> Cheers, >> Leif >> >> >> >> >> >> >> On Tue, Aug 19, 2014 at 2:13 PM, Lin Zhao <li...@ex...> wrote: >> >>> My previous post didn't get through so I'm reposting. >>> >>> I've been trying to use WrapperSimpleApp and have a >>> ClassNotFoundException that I can't explain. >>> >>> The .conf has the jar that includes the main class, and you can see from >>> the wrapper debug log that it's included to -classpath. But the wrapper >>> fails to find it. >>> >>> Attaching the wrapper debug log. >>> >>> In the log, you can see: >>> >>> *DEBUG | wrapper | 2014/08/18 15:19:08 | Command[7] : >>> ../lib/martini.jar:../lib/wrapper.jar* >>> >>> martini.jar has com.exabeam.martini.Martini, yet the wrapper can't find >>> it. >>> >>> *INFO | jvm 1 | 2014/08/18 15:19:08 | WrapperSimpleApp Error: >>> Unable to locate the class com.exabeam.martini.Martini : >>> java.lang.ClassNotFoundException: com.exabeam.martini.Martini* >>> When the wrapper repeatedly retries, I captured the task command (via >>> ps) as: >>> >>> *501 44180 44168 0 9:57PM ttys008 0:00.47 /usr/bin/java -d64 >>> -Dlog4j.configuration=file:///Users/lin/git/exabeam/martini/src/main/resources/log4j.properties >>> -Dspark.cleaner.ttl=300 -Xmx14000m -Djava.library.path=../lib -classpath >>> ../lib/martini.jar:../lib/wrapper.jar -Dwrapper.key=JXisZluSb14SpUBv >>> -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 >>> -Dwrapper.jvm.port.max=31999 -Dwrapper.debug=TRUE -Dwrapper.pid=44168 >>> -Dwrapper.version=3.5.25 -Dwrapper.native_library=wrapper >>> -Dwrapper.arch=universal -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=3 >>> org.tanukisoftware.wrapper.WrapperSimpleApp com.exabeam.martini.Martini >>> /Users/lin/git/exabeam/martini/config/custom/exabeam_config_imperva.conf* >>> >>> If I run below command directly, WrapperSimpleApp is able to find and >>> launch my main method, after which it failed for application specific >>> reason. >>> >>> *java -classpath ../lib/martini.jar:../lib/wrapper.jar >>> org.tanukisoftware.wrapper.WrapperSimpleApp com.exabeam.martini.Martini >>> /Users/lin/git/exabeam/martini/config/custom/exabeam_config_imperva.conf* >>> >>> Output: >>> >>> *WrapperManager: Initializing...* >>> >>> *WrapperManager: WARNING - The version of the Wrapper which launched >>> this JVM is* >>> >>> *WrapperManager: "unknown" while the version of the native >>> library* >>> >>> *WrapperManager: is "3.5.25".* >>> >>> *WrapperManager: The Wrapper may appear to work correctly but >>> some features may* >>> >>> *WrapperManager: not function correctly. This configuration >>> has not been tested* >>> >>> *WrapperManager: and is not supported.* >>> >>> *WrapperManager: * >>> >>> *2014-08-18 22:00:11.924 INFO ************************ >>> >>> *2014-08-18 22:00:11.925 INFO Martini started.* >>> Attaching the log and the conf. Thanks for the help. >>> >>> |
|
From: Lin Z. <li...@ex...> - 2014-09-01 22:40:26
|
Leif, Thanks for the reply. We already had it figured out. It's the java version. My jar is built with sbt, and somehow the java 6 jvm can't find the main class. Once I ensure the right java 7 JAVA_HOME it works. On Sep 1, 2014 12:58 AM, "Leif Mortenson" <lei...@ta...> wrote: > Lin, > I am sorry for the very slow reply. We somehow missed that this mail was > stuck in moderation. > > I think this is a problem with your working directory. Remember that > when the Wrapper runs, it ALWAYS forces the current working directory to be > the location of the wrapper binary. > This is done so that the Wrapper runs consistently regardless of how the > Wrapper is launched. > In your case, when running with the Wrapper, the working directory is: > /Users/lin/git/exabeam/martini/java-wrapper/bin > > I am not 100% sure what it is when you are running directly with your > command line. > In both cases, your classpath looks like this: > ../lib/martini.jar:../lib/wrapper.jar > > In the case of running with the Wrapper, this would mean that these files > are both located in the following directory: > /Users/lin/git/exabeam/martini/java-wrapper/lib > > A couple things that are confusing to me: > > 1) If the jar files had not been found, you would be seeing a message like > the following in the logs just before the JVM is launched: > DEBUG | wrapper | 2014/09/01 16:02:40.255 | | Classpath > element, wrapper.java.classpath.3, does not exist: ../lib/foo.jar > DEBUG | wrapper | 2014/09/01 16:02:40.255 | | Classpath > element, wrapper.java.classpath.4, does not exist: ../xxx/bar.jar > The lack of these messages in the log makes it look like both files exist > > 2) How are you launching the Wrapper? Is this on system startup? The > working directory of the parent that launched the Wrapper was the root > directory: > DEBUG | wrapper | 2014/08/18 22:06:42 | P--W- | WRAPPER_INIT_DIR=/ > This should not matter as the working directory was correctly changed to > the location of the Wrapper binary: > DEBUG | wrapper | 2014/08/18 22:06:42 | ---W- | > WRAPPER_WORKING_DIR=/Users/lin/git/exabeam/martini/java-wrapper/bin > > In both cases, the WrapperSimpleApp class is being located and loaded > correctly. That class simply locates the "com.exabeam.martini.Martini" > class by name in the same ClassLoader without doing anything special. > > If none of these hints help, would it be possible to get a tar of your > application sent to su...@ta...? We should only need the > martini.jar to be able to see if it locates your main class. But I am also > interested in seeing the relative location of files. > > Cheers, > Leif > > > > > > > On Tue, Aug 19, 2014 at 2:13 PM, Lin Zhao <li...@ex...> wrote: > >> My previous post didn't get through so I'm reposting. >> >> I've been trying to use WrapperSimpleApp and have a >> ClassNotFoundException that I can't explain. >> >> The .conf has the jar that includes the main class, and you can see from >> the wrapper debug log that it's included to -classpath. But the wrapper >> fails to find it. >> >> Attaching the wrapper debug log. >> >> In the log, you can see: >> >> *DEBUG | wrapper | 2014/08/18 15:19:08 | Command[7] : >> ../lib/martini.jar:../lib/wrapper.jar* >> >> martini.jar has com.exabeam.martini.Martini, yet the wrapper can't find >> it. >> >> *INFO | jvm 1 | 2014/08/18 15:19:08 | WrapperSimpleApp Error: Unable >> to locate the class com.exabeam.martini.Martini : >> java.lang.ClassNotFoundException: com.exabeam.martini.Martini* >> When the wrapper repeatedly retries, I captured the task command (via ps) >> as: >> >> *501 44180 44168 0 9:57PM ttys008 0:00.47 /usr/bin/java -d64 >> -Dlog4j.configuration=file:///Users/lin/git/exabeam/martini/src/main/resources/log4j.properties >> -Dspark.cleaner.ttl=300 -Xmx14000m -Djava.library.path=../lib -classpath >> ../lib/martini.jar:../lib/wrapper.jar -Dwrapper.key=JXisZluSb14SpUBv >> -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 >> -Dwrapper.jvm.port.max=31999 -Dwrapper.debug=TRUE -Dwrapper.pid=44168 >> -Dwrapper.version=3.5.25 -Dwrapper.native_library=wrapper >> -Dwrapper.arch=universal -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=3 >> org.tanukisoftware.wrapper.WrapperSimpleApp com.exabeam.martini.Martini >> /Users/lin/git/exabeam/martini/config/custom/exabeam_config_imperva.conf* >> >> If I run below command directly, WrapperSimpleApp is able to find and >> launch my main method, after which it failed for application specific >> reason. >> >> *java -classpath ../lib/martini.jar:../lib/wrapper.jar >> org.tanukisoftware.wrapper.WrapperSimpleApp com.exabeam.martini.Martini >> /Users/lin/git/exabeam/martini/config/custom/exabeam_config_imperva.conf* >> >> Output: >> >> *WrapperManager: Initializing...* >> >> *WrapperManager: WARNING - The version of the Wrapper which launched this >> JVM is* >> >> *WrapperManager: "unknown" while the version of the native >> library* >> >> *WrapperManager: is "3.5.25".* >> >> *WrapperManager: The Wrapper may appear to work correctly but >> some features may* >> >> *WrapperManager: not function correctly. This configuration >> has not been tested* >> >> *WrapperManager: and is not supported.* >> >> *WrapperManager: * >> >> *2014-08-18 22:00:11.924 INFO ************************ >> >> *2014-08-18 22:00:11.925 INFO Martini started.* >> Attaching the log and the conf. Thanks for the help. >> >> > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Leif M. <lei...@ta...> - 2014-09-01 07:56:25
|
Lin, I am sorry for the very slow reply. We somehow missed that this mail was stuck in moderation. I think this is a problem with your working directory. Remember that when the Wrapper runs, it ALWAYS forces the current working directory to be the location of the wrapper binary. This is done so that the Wrapper runs consistently regardless of how the Wrapper is launched. In your case, when running with the Wrapper, the working directory is: /Users/lin/git/exabeam/martini/java-wrapper/bin I am not 100% sure what it is when you are running directly with your command line. In both cases, your classpath looks like this: ../lib/martini.jar:../lib/wrapper.jar In the case of running with the Wrapper, this would mean that these files are both located in the following directory: /Users/lin/git/exabeam/martini/java-wrapper/lib A couple things that are confusing to me: 1) If the jar files had not been found, you would be seeing a message like the following in the logs just before the JVM is launched: DEBUG | wrapper | 2014/09/01 16:02:40.255 | | Classpath element, wrapper.java.classpath.3, does not exist: ../lib/foo.jar DEBUG | wrapper | 2014/09/01 16:02:40.255 | | Classpath element, wrapper.java.classpath.4, does not exist: ../xxx/bar.jar The lack of these messages in the log makes it look like both files exist 2) How are you launching the Wrapper? Is this on system startup? The working directory of the parent that launched the Wrapper was the root directory: DEBUG | wrapper | 2014/08/18 22:06:42 | P--W- | WRAPPER_INIT_DIR=/ This should not matter as the working directory was correctly changed to the location of the Wrapper binary: DEBUG | wrapper | 2014/08/18 22:06:42 | ---W- | WRAPPER_WORKING_DIR=/Users/lin/git/exabeam/martini/java-wrapper/bin In both cases, the WrapperSimpleApp class is being located and loaded correctly. That class simply locates the "com.exabeam.martini.Martini" class by name in the same ClassLoader without doing anything special. If none of these hints help, would it be possible to get a tar of your application sent to su...@ta...? We should only need the martini.jar to be able to see if it locates your main class. But I am also interested in seeing the relative location of files. Cheers, Leif On Tue, Aug 19, 2014 at 2:13 PM, Lin Zhao <li...@ex...> wrote: > My previous post didn't get through so I'm reposting. > > I've been trying to use WrapperSimpleApp and have a ClassNotFoundException > that I can't explain. > > The .conf has the jar that includes the main class, and you can see from > the wrapper debug log that it's included to -classpath. But the wrapper > fails to find it. > > Attaching the wrapper debug log. > > In the log, you can see: > > *DEBUG | wrapper | 2014/08/18 15:19:08 | Command[7] : > ../lib/martini.jar:../lib/wrapper.jar* > > martini.jar has com.exabeam.martini.Martini, yet the wrapper can't find > it. > > *INFO | jvm 1 | 2014/08/18 15:19:08 | WrapperSimpleApp Error: Unable > to locate the class com.exabeam.martini.Martini : > java.lang.ClassNotFoundException: com.exabeam.martini.Martini* > When the wrapper repeatedly retries, I captured the task command (via ps) > as: > > *501 44180 44168 0 9:57PM ttys008 0:00.47 /usr/bin/java -d64 > -Dlog4j.configuration=file:///Users/lin/git/exabeam/martini/src/main/resources/log4j.properties > -Dspark.cleaner.ttl=300 -Xmx14000m -Djava.library.path=../lib -classpath > ../lib/martini.jar:../lib/wrapper.jar -Dwrapper.key=JXisZluSb14SpUBv > -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 > -Dwrapper.jvm.port.max=31999 -Dwrapper.debug=TRUE -Dwrapper.pid=44168 > -Dwrapper.version=3.5.25 -Dwrapper.native_library=wrapper > -Dwrapper.arch=universal -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=3 > org.tanukisoftware.wrapper.WrapperSimpleApp com.exabeam.martini.Martini > /Users/lin/git/exabeam/martini/config/custom/exabeam_config_imperva.conf* > > If I run below command directly, WrapperSimpleApp is able to find and > launch my main method, after which it failed for application specific > reason. > > *java -classpath ../lib/martini.jar:../lib/wrapper.jar > org.tanukisoftware.wrapper.WrapperSimpleApp com.exabeam.martini.Martini > /Users/lin/git/exabeam/martini/config/custom/exabeam_config_imperva.conf* > > Output: > > *WrapperManager: Initializing...* > > *WrapperManager: WARNING - The version of the Wrapper which launched this > JVM is* > > *WrapperManager: "unknown" while the version of the native > library* > > *WrapperManager: is "3.5.25".* > > *WrapperManager: The Wrapper may appear to work correctly but > some features may* > > *WrapperManager: not function correctly. This configuration has > not been tested* > > *WrapperManager: and is not supported.* > > *WrapperManager: * > > *2014-08-18 22:00:11.924 INFO ************************ > > *2014-08-18 22:00:11.925 INFO Martini started.* > Attaching the log and the conf. Thanks for the help. > > |
|
From: Dittmar G. <gr...@if...> - 2014-08-19 02:40:50
|
Dittmar Gross ist wegen Urlaub bis 25-Aug-2014 nicht per eMail zu erreichen. Bitte wenden Sie sich in dringenden Faellen an Telefon +49 (69) 7680-50, Telefax +49 (69) 7680-5100 oder eMail fi...@if... Dittmar Gross is not available via eMail until Aug-25-2014 because of vacation. In urgent cases please contact us directly by Telephone +49 (69) 7680-50, Fax +49 (69) 7680-5100 or eMail fi...@if... ---------------------------------------------------------------------------- i:FAO Group Clemensstrasse 9, 60487 Frankfurt am Main, Germany Tel +49 (69) 7680-50, Fax +49 (69) 7680-5100, eMail information at ifao.net, www.cytric.info i:FAO Group GmbH Sitz in Frankfurt am Main Eingetragen beim Amtsgericht Frankfurt am Main, HRB 73600 Geschaeftsfuehrer: Louis Arnitz, Karin Froese To view the disclaimer text, click here: www.ifao.net/disclaimer |
|
From: Leif M. <lei...@ta...> - 2014-08-19 01:09:49
|
Lin, Could you please resend your wrapper.conf and wrapper.log files? It looks like there were some problems getting onto the list and the original mail with the attachments didn't come through. Also please make list posts to the wra...@li... address. The Wrapper reads the configuration file and uses that to build up the java command line. Once the JVM is launched however, it does its own classloading. The WrapperSimpleApp loads your main class within the JVM but does not do anything special with classloaders or the class path. I should be able to spot your problem with the wrapper.conf and wrapper.log files. I assume the path to the Martini-assembly-0.1-SNAPSHOT.jar file is correct. One problem I have seen in the past is with a corrupted jar file. Please make sure it has not been corrupted by an ASCII ftp transfer or anything like that. Cheers, Leif On Tue, Aug 19, 2014 at 7:46 AM, Lin Zhao <li...@ex...> wrote: > If I run the class directly like this, it successfully calls my main class: > > java -classpath > /Users/lin/git/exabeam/martini/target/scala-2.10/Martini-assembly-0.1-SNAPSHOT.jar:../lib/wrapper.jar > org.tanukisoftware.wrapper.WrapperSimpleApp com.exabeam.martini.Martini > On Mon, Aug 18, 2014 at 3:30 PM, <wra...@li... > > wrote: > >> >> ---------- Forwarded message ---------- >> From: Lin Zhao <li...@ex...> >> To: wra...@li... >> Cc: >> Date: Mon, 18 Aug 2014 15:24:26 -0700 >> Subject: ClassNotFoundException with WrapperSimpleApp >> Hi java wrapper subscribers, >> >> I've been trying to use WrapperSimpleApp and have a >> ClassNotFoundException that I can't explain. >> >> The .conf has the jar that includes the main class, and you can see from >> the wrapper debug log that it's included to -classpath. But the wrapper >> fails to find it. >> >> Attaching the wrapper debug log. >> >> In the log, you can see: >> >> *DEBUG | wrapper | 2014/08/18 15:19:08 | Command[7] : >> /Users/lin/git/exabeam/martini/target/scala-2.10/Martini-assembly-0.1-SNAPSHOT.jar:../lib/wrapper.jar* >> >> The snapshot jar has com.exabeam.martini.Martini, yet the wrapper can't >> find it. >> >> *INFO | jvm 1 | 2014/08/18 15:19:08 | WrapperSimpleApp Error: Unable >> to locate the class com.exabeam.martini.Martini : >> java.lang.ClassNotFoundException: com.exabeam.martini.Martini* >> >> Attaching the log and the conf. Thanks for the help. >> > > |
|
From: Leif M. <lei...@ta...> - 2014-07-14 06:18:56
|
Steven, I am sorry we did not notice right away. >From your log file, it looks like you are running version 3.3.3 of the Wrapper. Network sharing was not added until 3.5.0. http://wrapper.tanukisoftware.com/doc/english/prop-share-general.html Most likely the server that is working either already has the mapping setup or is using a newer version of the Wrapper. Could you please try upgrading to 3.5.25 and try this again? Thanks, Leif On Fri, Jul 11, 2014 at 2:34 PM, Alexandre Klein < ale...@ta...> wrote: > Hi Steve, > > In which situation you can see this problem: > 1) when Windows boot? > 2) once Windows is running? > > If situation #1: > Can it be a problem in the start order of the services ? > > If situation #2: > Can you try to run the Wrapper as a console ? > > Please let me know the result. > > In case you would like to send us some information that you don't want it > to be public, please use the following email: su...@ta... > > Best regards, > Alexandre Klein > > Alexandre Klein > Tanuki Software, Ltd. > 6-16-7-1001 Nishi-Kasai, Edogawa-ku > Tokyo 134-0088 Japan > Tel: +81-3-3878-3211 > Fax: +81-3-3878-0313 > http://www.tanukisoftware.com > > > On Wed, Jul 9, 2014 at 10:20 PM, Elkind, Steven <ste...@mh...> > wrote: > >> I'm using the wrapper indirectly - it's embedded in the Go continuous >> delivery agents we're using on Windows, to make them runnable as a Windows >> service. >> >> We're now trying to map a network share drive for our services, using the >> following set of properties in wrapper-agent.conf, that I was able to find >> the wrapper's online docs. However, this works on only one of our three >> Windows Server 2008R2 machines, but not on the other two. I have no clue >> as to why - even with wrapper.debug set to TRUE, there is no output in the >> wrapper log concerning the share mapping - on either the successful system >> or the other two. The logs on successful and unsuccessful machines look >> the same (sample from a log below my signature) >> >> >> # Mounting the shared drive for the build grid >> wrapper.debug=FALSE >> wrapper.share.1.location=\\sharehost.foo.com\BuildGridShare >> wrapper.share.1.target=P: >> wrapper.share.1.type=DISK >> wrapper.share.1.startup.premapped=CONTINUE >> wrapper.share.1.startup.max_retries=5 >> wrapper.share.1.startup.retry_interval=10 >> >> The service is configured to login in as the AD domain service user, >> hence no username and password in the above (I don't want the password in >> the clear on disk anyway). >> >> Does anyone have any ideas on how to troubleshoot this? See below for >> what I've done/tried so far. >> >> The product uses "Java Service Wrapper Standard Edition 3.3.3" >> >> More detail on some troubleshooting I've been doing: >> >> Our Windows admins claim that all three have the drive mapped for the >> service user at boot time, and all in the same way. The drive _is_ >> map-able - I can see the drive mounted on all three if I login to the >> desktop as the service user, or I can map it manually when logged as >> another user. However, the Windows services running with the wrapper on >> the two machines don't see it. >> >> I can also map it using the command "net use P: \\sharehost.foo.com\BuildGridShare" >> in a Windows batch script run by the Go Agent as a job, but many of the >> jobs we have do not run batch scripts, instead directly invoking Ant, >> Maven, or other tools without a script wrapping them - so that's not a >> viable solution. >> >> I can find nothing in the Windows event log. >> >> Thanks in advance for any help.... >> >> Steve Elkind >> ste...@mh... >> >> >> >> DEBUG | wrapper | 2014/07/08 12:48:01 | Allocating a console for the >> service. >> DEBUG | wrapper | 2014/07/08 12:48:01 | Found console window. >> STATUS | wrapper | 2014/07/08 12:48:01 | --> Wrapper Started as Service >> STATUS | wrapper | 2014/07/08 12:48:01 | Java Service Wrapper Standard >> Edition 3.3.3 >> STATUS | wrapper | 2014/07/08 12:48:01 | Copyright (C) 1999-2009 >> Tanuki Software, Ltd. All Rights Reserved. >> STATUS | wrapper | 2014/07/08 12:48:01 | >> http://wrapper.tanukisoftware.org >> STATUS | wrapper | 2014/07/08 12:48:01 | Licensed to ThoughtWorks for >> Cruise Agent >> STATUS | wrapper | 2014/07/08 12:48:01 | >> DEBUG | wrapper | 2014/07/08 12:48:01 | Using tick timer. >> DEBUG | wrapperp | 2014/07/08 12:48:01 | server listening on port 32007. >> DEBUG | wrapper | 2014/07/08 12:48:01 | Ping settings: >> wrapper.ping.interval=5, wrapper.ping.interval.logged=1, >> wrapper.ping.timeout=30 >> STATUS | wrapper | 2014/07/08 12:48:01 | Launching a JVM... >> DEBUG | wrapper | 2014/07/08 12:48:01 | command: >> "D:\BuildTools\HarmonyGoProdAgent\jdk\bin\java" >> -Done-jar.main.class=com.thoughtworks.cruise.agent.AgentBootstrapper >> "-DJAVA_SYS_MON_TEMP_DIR=D:\BuildTools\HarmonyGoProdAgent\tmp" >> -Djava.library.path="lib" -classpath >> "lib/wrappertest.jar;lib/wrapper.jar;agent-bootstrapper.jar" >> -Dwrapper.key="LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ" -Dwrapper.port=32007 >> -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 >> -Dwrapper.debug="TRUE" -Dwrapper.pid=2848 -Dwrapper.version="3.3.3-st" >> -Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE" >> -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 >> org.tanukisoftware.wrapper.WrapperSimpleApp com.simontuffs.onejar.Boot >> im-go.mhf.mhc 8153 >> DEBUG | wrapper | 2014/07/08 12:48:01 | JVM started (PID=3584) >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> WrapperManager class initialized by thread: main Using classloader: >> sun.misc.Launcher$AppClassLoader@14fe5c >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager: Initializing... >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: JVM #1 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Running a >> 32-bit JVM. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> Registering shutdown hook >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Using >> wrapper >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Load >> native library. One or more attempts may fail if platform specific >> libraries do not exist. This is NORMAL and is only a problem if they all >> fail. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Unable >> to load native library: wrapper-windows-x86-32.dll Cause: no >> wrapper-windows-x86-32 in java.library.path >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Loaded >> native library: wrapper.dll >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Calling >> native initialization method. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Initializing >> WrapperManager native library. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Java >> Executable: D:\BuildTools\HarmonyGoProdAgent\jdk\bin\java.exe >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Windows >> version: 6.1.7600 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Java >> Version : 1.6.0_17-b04 Java HotSpot(TM) Client VM >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Java VM >> Vendor : Sun Microsystems Inc. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: OS Name >> : Windows Server 2008 R2 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: OS Arch >> : x86 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Control >> event monitor thread started. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Startup >> runner thread started. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> WrapperManager.start(org.tanukisoftware.wrapper.WrapperSimpleApp@6e3d60, >> args["im-go.mhf.mhc", "8153"]) called by thread: main >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> Communications runner thread started. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Open >> socket to wrapper...Wrapper-Connection >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed >> attempt to bind using local port 31000 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed >> attempt to bind using local port 31001 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed >> attempt to bind using local port 31002 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed >> attempt to bind using local port 31003 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed >> attempt to bind using local port 31004 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed >> attempt to bind using local port 31005 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed >> attempt to bind using local port 31006 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed >> attempt to bind using local port 31007 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Opened >> Socket from 31008 to 32007 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Send a >> packet KEY : LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> handleSocket(Socket[addr=/127.0.0.1,port=32007,localport=31008]) >> DEBUG | wrapperp | 2014/07/08 12:48:02 | accepted a socket from >> 127.0.0.1 on port 31008 >> DEBUG | wrapperp | 2014/07/08 12:48:02 | read a packet KEY : >> LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ >> DEBUG | wrapper | 2014/07/08 12:48:02 | Got key from JVM: >> LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ >> DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet LOW_LOG_LEVEL : 1 >> DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet PING_TIMEOUT : 30 >> DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet PROPERTIES : >> (Property Values) >> DEBUG | wrapper | 2014/07/08 12:48:02 | Start Application. >> DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet START : start >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received >> a packet LOW_LOG_LEVEL : 1 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> LowLogLevel from Wrapper is 1 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received >> a packet PING_TIMEOUT : 30 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> PingTimeout from Wrapper is 30000 >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received >> a packet PROPERTIES : (Property Values) >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received >> a packet START : start >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: calling >> WrapperListener.start() >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: >> WrapperListener.start runner thread started. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperSimpleApp Debug: >> start(args) Will wait up to 2 seconds for the main method to complete. >> INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperSimpleApp Debug: >> invoking main method >> 2014-07-08 12:48:02,685 [WrapperSimpleAppMain] INFO >> thoughtworks.cruise.agent.ServerAgentDownloader:112 - download started at >> Tue Jul 08 12:48:02 EDT 2014 >> 2014-07-08 12:48:02,685 [WrapperSimpleAppMain] INFO >> thoughtworks.cruise.agent.ServerAgentDownloader:118 - got server response >> at Tue Jul 08 12:48:02 EDT 2014 >> INFO | jvm 1 | 2014/07/08 12:48:03 | WrapperManager Debug: Send a >> packet START_PENDING : 5000 >> DEBUG | wrapperp | 2014/07/08 12:48:03 | read a packet START_PENDING : >> 5000 >> DEBUG | wrapper | 2014/07/08 12:48:03 | JVM signalled a start pending >> with waitHint of 5000 millis. >> INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Send a >> packet START_PENDING : 5000 >> INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperSimpleApp Debug: >> start(args) end. Main Completed=false, exitCode=null >> INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: returned >> from WrapperListener.start() >> INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Send a >> packet STARTED : >> INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: >> WrapperListener.start runner thread stopped. >> INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Startup >> runner thread stopped. >> DEBUG | wrapperp | 2014/07/08 12:48:04 | read a packet START_PENDING : >> 5000 >> DEBUG | wrapper | 2014/07/08 12:48:04 | JVM signalled a start pending >> with waitHint of 5000 millis. >> DEBUG | wrapperp | 2014/07/08 12:48:04 | read a packet STARTED : >> DEBUG | wrapper | 2014/07/08 12:48:04 | JVM signalled that it was >> started. >> DEBUG | wrapperp | 2014/07/08 12:48:06 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:06 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:06 | WrapperManager Debug: Send a >> packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:06 | read a packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:10 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:10 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:10 | WrapperManager Debug: Send a >> packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:10 | read a packet PING : ping >> 2014-07-08 12:48:13,264 [WrapperSimpleAppMain] INFO >> thoughtworks.cruise.agent.ServerAgentDownloader:121 - pipe the stream to >> agent.jar atTue Jul 08 12:48:13 EDT 2014 >> 2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO >> thoughtworks.cruise.util.PerfTimer:37 - Performance: Downloading new agent >> with md5 signature: dKqUVC2fvLstTHvB8Ag6MQ== took 10609ms >> 2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO >> thoughtworks.cruise.agent.AgentBootstrapper:100 - Agent is version: 2.3.1 >> 2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO >> thoughtworks.cruise.agent.AgentBootstrapper:101 - Launching Agent with >> command: D:\BuildTools\HarmonyGoProdAgent\jdk\jre\bin\java -Xms128m >> -Xmx256m "-DJAVA_SYS_MON_TEMP_DIR=D:\BuildTools\HarmonyGoProdAgent\tmp" >> -Dagent.binary.md5=dKqUVC2fvLstTHvB8Ag6MQ== -jar agent.jar >> https://im-go.mhf.mhc:8154/go/ >> DEBUG | wrapperp | 2014/07/08 12:48:15 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:15 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:15 | WrapperManager Debug: Send a >> packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:15 | read a packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:19 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:19 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:19 | WrapperManager Debug: Send a >> packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:19 | read a packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:24 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:24 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:24 | WrapperManager Debug: Send a >> packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:24 | read a packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:28 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:28 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:28 | WrapperManager Debug: Send a >> packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:28 | read a packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:33 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:33 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:33 | WrapperManager Debug: Send a >> packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:33 | read a packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:34 | send a packet >> SERVICE_CONTROL_CODE : 4 >> DEBUG | wrapper | 2014/07/08 12:48:34 | SERVICE_CONTROL_INTERROGATE >> INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: Received >> a packet SERVICE_CONTROL_CODE : 4 >> INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: >> ServiceControlCode from Wrapper with code 4 >> DEBUG | wrapperp | 2014/07/08 12:48:34 | send a packet >> SERVICE_CONTROL_CODE : 4 >> DEBUG | wrapper | 2014/07/08 12:48:34 | SERVICE_CONTROL_INTERROGATE >> INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: Received >> a packet SERVICE_CONTROL_CODE : 4 >> INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: >> ServiceControlCode from Wrapper with code 4 >> DEBUG | wrapperp | 2014/07/08 12:48:37 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:37 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:37 | WrapperManager Debug: Send a >> packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:37 | read a packet PING : ping >> DEBUG | wrapperp | 2014/07/08 12:48:42 | send a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:42 | WrapperManager Debug: Received >> a packet PING : ping >> INFO | jvm 1 | 2014/07/08 12:48:42 | WrapperManager Debug: Send a >> packet PING : ping >> > |
|
From: Dannes W. <da...@ex...> - 2014-07-12 08:29:05
|
Hi Alexandre, On 11 Jul 2014, at 5:46 , Alexandre Klein <ale...@ta...> wrote: > Can you add this property in wrapper.conf: > wrapper.startup.timeout=300 > Please take the time to read this page: http://wrapper.tanukisoftware.com/doc/english/prop-startup-timeout.html that seem to do the trick; I guess the software takes a looooong time to start, making the Main return too late. thnx for the hint! regards Dannes |
|
From: Alexandre K. <ale...@ta...> - 2014-07-11 05:35:04
|
Hi Steve, In which situation you can see this problem: 1) when Windows boot? 2) once Windows is running? If situation #1: Can it be a problem in the start order of the services ? If situation #2: Can you try to run the Wrapper as a console ? Please let me know the result. In case you would like to send us some information that you don't want it to be public, please use the following email: su...@ta... Best regards, Alexandre Klein Alexandre Klein Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel: +81-3-3878-3211 Fax: +81-3-3878-0313 http://www.tanukisoftware.com On Wed, Jul 9, 2014 at 10:20 PM, Elkind, Steven <ste...@mh...> wrote: > I'm using the wrapper indirectly - it's embedded in the Go continuous > delivery agents we're using on Windows, to make them runnable as a Windows > service. > > We're now trying to map a network share drive for our services, using the > following set of properties in wrapper-agent.conf, that I was able to find > the wrapper's online docs. However, this works on only one of our three > Windows Server 2008R2 machines, but not on the other two. I have no clue > as to why - even with wrapper.debug set to TRUE, there is no output in the > wrapper log concerning the share mapping - on either the successful system > or the other two. The logs on successful and unsuccessful machines look > the same (sample from a log below my signature) > > > # Mounting the shared drive for the build grid > wrapper.debug=FALSE > wrapper.share.1.location=\\sharehost.foo.com\BuildGridShare > wrapper.share.1.target=P: > wrapper.share.1.type=DISK > wrapper.share.1.startup.premapped=CONTINUE > wrapper.share.1.startup.max_retries=5 > wrapper.share.1.startup.retry_interval=10 > > The service is configured to login in as the AD domain service user, hence > no username and password in the above (I don't want the password in the > clear on disk anyway). > > Does anyone have any ideas on how to troubleshoot this? See below for > what I've done/tried so far. > > The product uses "Java Service Wrapper Standard Edition 3.3.3" > > More detail on some troubleshooting I've been doing: > > Our Windows admins claim that all three have the drive mapped for the > service user at boot time, and all in the same way. The drive _is_ > map-able - I can see the drive mounted on all three if I login to the > desktop as the service user, or I can map it manually when logged as > another user. However, the Windows services running with the wrapper on > the two machines don't see it. > > I can also map it using the command "net use P: \\sharehost.foo.com\BuildGridShare" > in a Windows batch script run by the Go Agent as a job, but many of the > jobs we have do not run batch scripts, instead directly invoking Ant, > Maven, or other tools without a script wrapping them - so that's not a > viable solution. > > I can find nothing in the Windows event log. > > Thanks in advance for any help.... > > Steve Elkind > ste...@mh... > > > > DEBUG | wrapper | 2014/07/08 12:48:01 | Allocating a console for the > service. > DEBUG | wrapper | 2014/07/08 12:48:01 | Found console window. > STATUS | wrapper | 2014/07/08 12:48:01 | --> Wrapper Started as Service > STATUS | wrapper | 2014/07/08 12:48:01 | Java Service Wrapper Standard > Edition 3.3.3 > STATUS | wrapper | 2014/07/08 12:48:01 | Copyright (C) 1999-2009 Tanuki > Software, Ltd. All Rights Reserved. > STATUS | wrapper | 2014/07/08 12:48:01 | > http://wrapper.tanukisoftware.org > STATUS | wrapper | 2014/07/08 12:48:01 | Licensed to ThoughtWorks for > Cruise Agent > STATUS | wrapper | 2014/07/08 12:48:01 | > DEBUG | wrapper | 2014/07/08 12:48:01 | Using tick timer. > DEBUG | wrapperp | 2014/07/08 12:48:01 | server listening on port 32007. > DEBUG | wrapper | 2014/07/08 12:48:01 | Ping settings: > wrapper.ping.interval=5, wrapper.ping.interval.logged=1, > wrapper.ping.timeout=30 > STATUS | wrapper | 2014/07/08 12:48:01 | Launching a JVM... > DEBUG | wrapper | 2014/07/08 12:48:01 | command: > "D:\BuildTools\HarmonyGoProdAgent\jdk\bin\java" > -Done-jar.main.class=com.thoughtworks.cruise.agent.AgentBootstrapper > "-DJAVA_SYS_MON_TEMP_DIR=D:\BuildTools\HarmonyGoProdAgent\tmp" > -Djava.library.path="lib" -classpath > "lib/wrappertest.jar;lib/wrapper.jar;agent-bootstrapper.jar" > -Dwrapper.key="LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ" -Dwrapper.port=32007 > -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 > -Dwrapper.debug="TRUE" -Dwrapper.pid=2848 -Dwrapper.version="3.3.3-st" > -Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE" > -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 > org.tanukisoftware.wrapper.WrapperSimpleApp com.simontuffs.onejar.Boot > im-go.mhf.mhc 8153 > DEBUG | wrapper | 2014/07/08 12:48:01 | JVM started (PID=3584) > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > WrapperManager class initialized by thread: main Using classloader: > sun.misc.Launcher$AppClassLoader@14fe5c > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager: Initializing... > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: JVM #1 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Running a > 32-bit JVM. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > Registering shutdown hook > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Using > wrapper > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Load > native library. One or more attempts may fail if platform specific > libraries do not exist. This is NORMAL and is only a problem if they all > fail. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Unable > to load native library: wrapper-windows-x86-32.dll Cause: no > wrapper-windows-x86-32 in java.library.path > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Loaded > native library: wrapper.dll > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Calling > native initialization method. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Initializing > WrapperManager native library. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Java > Executable: D:\BuildTools\HarmonyGoProdAgent\jdk\bin\java.exe > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Windows > version: 6.1.7600 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Java > Version : 1.6.0_17-b04 Java HotSpot(TM) Client VM > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Java VM > Vendor : Sun Microsystems Inc. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: OS Name > : Windows Server 2008 R2 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: OS Arch > : x86 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Control > event monitor thread started. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Startup > runner thread started. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > WrapperManager.start(org.tanukisoftware.wrapper.WrapperSimpleApp@6e3d60, > args["im-go.mhf.mhc", "8153"]) called by thread: main > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > Communications runner thread started. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Open > socket to wrapper...Wrapper-Connection > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed > attempt to bind using local port 31000 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed > attempt to bind using local port 31001 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed > attempt to bind using local port 31002 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed > attempt to bind using local port 31003 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed > attempt to bind using local port 31004 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed > attempt to bind using local port 31005 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed > attempt to bind using local port 31006 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed > attempt to bind using local port 31007 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Opened > Socket from 31008 to 32007 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Send a > packet KEY : LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > handleSocket(Socket[addr=/127.0.0.1,port=32007,localport=31008]) > DEBUG | wrapperp | 2014/07/08 12:48:02 | accepted a socket from 127.0.0.1 > on port 31008 > DEBUG | wrapperp | 2014/07/08 12:48:02 | read a packet KEY : > LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ > DEBUG | wrapper | 2014/07/08 12:48:02 | Got key from JVM: > LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ > DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet LOW_LOG_LEVEL : 1 > DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet PING_TIMEOUT : 30 > DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet PROPERTIES : > (Property Values) > DEBUG | wrapper | 2014/07/08 12:48:02 | Start Application. > DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet START : start > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received a > packet LOW_LOG_LEVEL : 1 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > LowLogLevel from Wrapper is 1 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received a > packet PING_TIMEOUT : 30 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > PingTimeout from Wrapper is 30000 > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received a > packet PROPERTIES : (Property Values) > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received a > packet START : start > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: calling > WrapperListener.start() > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: > WrapperListener.start runner thread started. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperSimpleApp Debug: > start(args) Will wait up to 2 seconds for the main method to complete. > INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperSimpleApp Debug: invoking > main method > 2014-07-08 12:48:02,685 [WrapperSimpleAppMain] INFO > thoughtworks.cruise.agent.ServerAgentDownloader:112 - download started at > Tue Jul 08 12:48:02 EDT 2014 > 2014-07-08 12:48:02,685 [WrapperSimpleAppMain] INFO > thoughtworks.cruise.agent.ServerAgentDownloader:118 - got server response > at Tue Jul 08 12:48:02 EDT 2014 > INFO | jvm 1 | 2014/07/08 12:48:03 | WrapperManager Debug: Send a > packet START_PENDING : 5000 > DEBUG | wrapperp | 2014/07/08 12:48:03 | read a packet START_PENDING : > 5000 > DEBUG | wrapper | 2014/07/08 12:48:03 | JVM signalled a start pending > with waitHint of 5000 millis. > INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Send a > packet START_PENDING : 5000 > INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperSimpleApp Debug: > start(args) end. Main Completed=false, exitCode=null > INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: returned > from WrapperListener.start() > INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Send a > packet STARTED : > INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: > WrapperListener.start runner thread stopped. > INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Startup > runner thread stopped. > DEBUG | wrapperp | 2014/07/08 12:48:04 | read a packet START_PENDING : > 5000 > DEBUG | wrapper | 2014/07/08 12:48:04 | JVM signalled a start pending > with waitHint of 5000 millis. > DEBUG | wrapperp | 2014/07/08 12:48:04 | read a packet STARTED : > DEBUG | wrapper | 2014/07/08 12:48:04 | JVM signalled that it was > started. > DEBUG | wrapperp | 2014/07/08 12:48:06 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:06 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:06 | WrapperManager Debug: Send a > packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:06 | read a packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:10 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:10 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:10 | WrapperManager Debug: Send a > packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:10 | read a packet PING : ping > 2014-07-08 12:48:13,264 [WrapperSimpleAppMain] INFO > thoughtworks.cruise.agent.ServerAgentDownloader:121 - pipe the stream to > agent.jar atTue Jul 08 12:48:13 EDT 2014 > 2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO > thoughtworks.cruise.util.PerfTimer:37 - Performance: Downloading new agent > with md5 signature: dKqUVC2fvLstTHvB8Ag6MQ== took 10609ms > 2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO > thoughtworks.cruise.agent.AgentBootstrapper:100 - Agent is version: 2.3.1 > 2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO > thoughtworks.cruise.agent.AgentBootstrapper:101 - Launching Agent with > command: D:\BuildTools\HarmonyGoProdAgent\jdk\jre\bin\java -Xms128m > -Xmx256m "-DJAVA_SYS_MON_TEMP_DIR=D:\BuildTools\HarmonyGoProdAgent\tmp" > -Dagent.binary.md5=dKqUVC2fvLstTHvB8Ag6MQ== -jar agent.jar > https://im-go.mhf.mhc:8154/go/ > DEBUG | wrapperp | 2014/07/08 12:48:15 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:15 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:15 | WrapperManager Debug: Send a > packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:15 | read a packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:19 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:19 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:19 | WrapperManager Debug: Send a > packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:19 | read a packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:24 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:24 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:24 | WrapperManager Debug: Send a > packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:24 | read a packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:28 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:28 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:28 | WrapperManager Debug: Send a > packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:28 | read a packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:33 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:33 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:33 | WrapperManager Debug: Send a > packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:33 | read a packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:34 | send a packet > SERVICE_CONTROL_CODE : 4 > DEBUG | wrapper | 2014/07/08 12:48:34 | SERVICE_CONTROL_INTERROGATE > INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: Received a > packet SERVICE_CONTROL_CODE : 4 > INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: > ServiceControlCode from Wrapper with code 4 > DEBUG | wrapperp | 2014/07/08 12:48:34 | send a packet > SERVICE_CONTROL_CODE : 4 > DEBUG | wrapper | 2014/07/08 12:48:34 | SERVICE_CONTROL_INTERROGATE > INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: Received a > packet SERVICE_CONTROL_CODE : 4 > INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: > ServiceControlCode from Wrapper with code 4 > DEBUG | wrapperp | 2014/07/08 12:48:37 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:37 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:37 | WrapperManager Debug: Send a > packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:37 | read a packet PING : ping > DEBUG | wrapperp | 2014/07/08 12:48:42 | send a packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:42 | WrapperManager Debug: Received a > packet PING : ping > INFO | jvm 1 | 2014/07/08 12:48:42 | WrapperManager Debug: Send a > packet PING : ping > > > > The information contained in this message is intended only for the > recipient, and may be a confidential attorney-client communication or may > otherwise be privileged and confidential and protected from disclosure. If > the reader of this message is not the intended recipient, or an employee or > agent responsible for delivering this message to the intended recipient, > please be aware that any dissemination or copying of this communication is > strictly prohibited. If you have received this communication in error, > please immediately notify us by replying to the message and deleting it > from your computer. McGraw Hill Financial reserves the right, subject to > applicable local law, to monitor, review and process the content of any > electronic message or information sent to or from McGraw Hill Financial > e-mail addresses without informing the sender or recipient of the message. > By sending electronic message or information to McGraw Hill Financial > e-mail addresses you, as the sender, are consenting to McGraw Hill > Financial processing any of your personal data therein. > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Alexandre K. <ale...@ta...> - 2014-07-11 04:17:57
|
Dannes, Sorry for the delay. It looks like there is a problem when the JVM is starting. Can you add this property in wrapper.conf: wrapper.startup.timeout=300 Please take the time to read this page: http://wrapper.tanukisoftware.com/doc/english/prop-startup-timeout.html Does the start method in your main class (org.exist.wrapper.Main) is returning upon completion? Best regards, Alexandre Klein Alexandre Klein Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel: +81-3-3878-3211 Fax: +81-3-3878-0313 http://www.tanukisoftware.com On Sun, Jul 6, 2014 at 12:53 AM, Dannes Wessels <da...@ex...> wrote: > Hi, > > For some time now I have some issues to get my application started via the > service wrapper during boot time of MacOSX ; the first issues appeared when > I upgraded to Mountain Lion, it is still there with Mavericks; Upgrading to > a more recent version of the wrapper did not help; I have been ignoring the > issue for quite some time now, I think it is time to get grip on the issue > right now :-) > > Some details > > - The wrapper has been installed with the 'wrapper.sh install' command > - The application is started at system boot (the wrapper code writes > to logfile, application writes logs too) > - but after some time there is a SigKill(9), see log files, > application dies > > > Some details worth to be mentioned: > > - with 'wrapper.sh start' the application is always started without > problems > - when started manually via launchctl the application always starts > (so: the issue seems only to be present at startup time) > - under linux no issues have been reported > > > My System: > > - MacOSX 10.9.4 (server) > - Latest 64bit Java7 > - Java Service Wrapper Community Edition 64-bit 3.5.23 > > > The .conf and .log files are attached; Please could you provide me some > hints on what to change to get my application started again at every system > reboot? > > I suspect that the Launchd terminates the service-wrapper, but I am not > sure how to diagnose. > > Kind regards > > Dannes > > > > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Elkind, S. <ste...@mh...> - 2014-07-09 13:54:56
|
I'm using the wrapper indirectly - it's embedded in the Go continuous delivery agents we're using on Windows, to make them runnable as a Windows service.
We're now trying to map a network share drive for our services, using the following set of properties in wrapper-agent.conf, that I was able to find the wrapper's online docs. However, this works on only one of our three Windows Server 2008R2 machines, but not on the other two. I have no clue as to why - even with wrapper.debug set to TRUE, there is no output in the wrapper log concerning the share mapping - on either the successful system or the other two. The logs on successful and unsuccessful machines look the same (sample from a log below my signature)
# Mounting the shared drive for the build grid
wrapper.debug=FALSE
wrapper.share.1.location=\\sharehost.foo.com\BuildGridShare
wrapper.share.1.target=P:
wrapper.share.1.type=DISK
wrapper.share.1.startup.premapped=CONTINUE
wrapper.share.1.startup.max_retries=5
wrapper.share.1.startup.retry_interval=10
The service is configured to login in as the AD domain service user, hence no username and password in the above (I don't want the password in the clear on disk anyway).
Does anyone have any ideas on how to troubleshoot this? See below for what I've done/tried so far.
The product uses "Java Service Wrapper Standard Edition 3.3.3"
More detail on some troubleshooting I've been doing:
Our Windows admins claim that all three have the drive mapped for the service user at boot time, and all in the same way. The drive _is_ map-able - I can see the drive mounted on all three if I login to the desktop as the service user, or I can map it manually when logged as another user. However, the Windows services running with the wrapper on the two machines don't see it.
I can also map it using the command "net use P: \\sharehost.foo.com\BuildGridShare" in a Windows batch script run by the Go Agent as a job, but many of the jobs we have do not run batch scripts, instead directly invoking Ant, Maven, or other tools without a script wrapping them - so that's not a viable solution.
I can find nothing in the Windows event log.
Thanks in advance for any help....
Steve Elkind
ste...@mh...
DEBUG | wrapper | 2014/07/08 12:48:01 | Allocating a console for the service.
DEBUG | wrapper | 2014/07/08 12:48:01 | Found console window.
STATUS | wrapper | 2014/07/08 12:48:01 | --> Wrapper Started as Service
STATUS | wrapper | 2014/07/08 12:48:01 | Java Service Wrapper Standard Edition 3.3.3
STATUS | wrapper | 2014/07/08 12:48:01 | Copyright (C) 1999-2009 Tanuki Software, Ltd. All Rights Reserved.
STATUS | wrapper | 2014/07/08 12:48:01 | http://wrapper.tanukisoftware.org
STATUS | wrapper | 2014/07/08 12:48:01 | Licensed to ThoughtWorks for Cruise Agent
STATUS | wrapper | 2014/07/08 12:48:01 |
DEBUG | wrapper | 2014/07/08 12:48:01 | Using tick timer.
DEBUG | wrapperp | 2014/07/08 12:48:01 | server listening on port 32007.
DEBUG | wrapper | 2014/07/08 12:48:01 | Ping settings: wrapper.ping.interval=5, wrapper.ping.interval.logged=1, wrapper.ping.timeout=30
STATUS | wrapper | 2014/07/08 12:48:01 | Launching a JVM...
DEBUG | wrapper | 2014/07/08 12:48:01 | command: "D:\BuildTools\HarmonyGoProdAgent\jdk\bin\java" -Done-jar.main.class=com.thoughtworks.cruise.agent.AgentBootstrapper "-DJAVA_SYS_MON_TEMP_DIR=D:\BuildTools\HarmonyGoProdAgent\tmp" -Djava.library.path="lib" -classpath "lib/wrappertest.jar;lib/wrapper.jar;agent-bootstrapper.jar" -Dwrapper.key="LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ" -Dwrapper.port=32007 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.debug="TRUE" -Dwrapper.pid=2848 -Dwrapper.version="3.3.3-st" -Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp com.simontuffs.onejar.Boot im-go.mhf.mhc 8153
DEBUG | wrapper | 2014/07/08 12:48:01 | JVM started (PID=3584)
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: WrapperManager class initialized by thread: main Using classloader: sun.misc.Launcher$AppClassLoader@14fe5c
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager: Initializing...
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: JVM #1
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Running a 32-bit JVM.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Registering shutdown hook
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Using wrapper
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Load native library. One or more attempts may fail if platform specific libraries do not exist. This is NORMAL and is only a problem if they all fail.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Unable to load native library: wrapper-windows-x86-32.dll Cause: no wrapper-windows-x86-32 in java.library.path
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Loaded native library: wrapper.dll
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Calling native initialization method.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Initializing WrapperManager native library.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Java Executable: D:\BuildTools\HarmonyGoProdAgent\jdk\bin\java.exe
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperJNI Debug: Windows version: 6.1.7600
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Java Version : 1.6.0_17-b04 Java HotSpot(TM) Client VM
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Java VM Vendor : Sun Microsystems Inc.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: OS Name : Windows Server 2008 R2
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: OS Arch : x86
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug:
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Control event monitor thread started.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Startup runner thread started.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: WrapperManager.start(org.tanukisoftware.wrapper.WrapperSimpleApp@6e3d60, args["im-go.mhf.mhc", "8153"]) called by thread: main
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Communications runner thread started.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Open socket to wrapper...Wrapper-Connection
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed attempt to bind using local port 31000
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed attempt to bind using local port 31001
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed attempt to bind using local port 31002
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed attempt to bind using local port 31003
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed attempt to bind using local port 31004
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed attempt to bind using local port 31005
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed attempt to bind using local port 31006
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Failed attempt to bind using local port 31007
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Opened Socket from 31008 to 32007
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Send a packet KEY : LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: handleSocket(Socket[addr=/127.0.0.1,port=32007,localport=31008])
DEBUG | wrapperp | 2014/07/08 12:48:02 | accepted a socket from 127.0.0.1 on port 31008
DEBUG | wrapperp | 2014/07/08 12:48:02 | read a packet KEY : LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ
DEBUG | wrapper | 2014/07/08 12:48:02 | Got key from JVM: LiT74k9ZeQSYB64rkyC56s3QjKXhPcnQ
DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet LOW_LOG_LEVEL : 1
DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet PING_TIMEOUT : 30
DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet PROPERTIES : (Property Values)
DEBUG | wrapper | 2014/07/08 12:48:02 | Start Application.
DEBUG | wrapperp | 2014/07/08 12:48:02 | send a packet START : start
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received a packet LOW_LOG_LEVEL : 1
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: LowLogLevel from Wrapper is 1
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received a packet PING_TIMEOUT : 30
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: PingTimeout from Wrapper is 30000
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received a packet PROPERTIES : (Property Values)
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: Received a packet START : start
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: calling WrapperListener.start()
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperManager Debug: WrapperListener.start runner thread started.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperSimpleApp Debug: start(args) Will wait up to 2 seconds for the main method to complete.
INFO | jvm 1 | 2014/07/08 12:48:02 | WrapperSimpleApp Debug: invoking main method
2014-07-08 12:48:02,685 [WrapperSimpleAppMain] INFO thoughtworks.cruise.agent.ServerAgentDownloader:112 - download started at Tue Jul 08 12:48:02 EDT 2014
2014-07-08 12:48:02,685 [WrapperSimpleAppMain] INFO thoughtworks.cruise.agent.ServerAgentDownloader:118 - got server response at Tue Jul 08 12:48:02 EDT 2014
INFO | jvm 1 | 2014/07/08 12:48:03 | WrapperManager Debug: Send a packet START_PENDING : 5000
DEBUG | wrapperp | 2014/07/08 12:48:03 | read a packet START_PENDING : 5000
DEBUG | wrapper | 2014/07/08 12:48:03 | JVM signalled a start pending with waitHint of 5000 millis.
INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Send a packet START_PENDING : 5000
INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperSimpleApp Debug: start(args) end. Main Completed=false, exitCode=null
INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: returned from WrapperListener.start()
INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Send a packet STARTED :
INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: WrapperListener.start runner thread stopped.
INFO | jvm 1 | 2014/07/08 12:48:04 | WrapperManager Debug: Startup runner thread stopped.
DEBUG | wrapperp | 2014/07/08 12:48:04 | read a packet START_PENDING : 5000
DEBUG | wrapper | 2014/07/08 12:48:04 | JVM signalled a start pending with waitHint of 5000 millis.
DEBUG | wrapperp | 2014/07/08 12:48:04 | read a packet STARTED :
DEBUG | wrapper | 2014/07/08 12:48:04 | JVM signalled that it was started.
DEBUG | wrapperp | 2014/07/08 12:48:06 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:06 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:06 | WrapperManager Debug: Send a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:06 | read a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:10 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:10 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:10 | WrapperManager Debug: Send a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:10 | read a packet PING : ping
2014-07-08 12:48:13,264 [WrapperSimpleAppMain] INFO thoughtworks.cruise.agent.ServerAgentDownloader:121 - pipe the stream to agent.jar atTue Jul 08 12:48:13 EDT 2014
2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO thoughtworks.cruise.util.PerfTimer:37 - Performance: Downloading new agent with md5 signature: dKqUVC2fvLstTHvB8Ag6MQ== took 10609ms
2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO thoughtworks.cruise.agent.AgentBootstrapper:100 - Agent is version: 2.3.1
2014-07-08 12:48:13,279 [WrapperSimpleAppMain] INFO thoughtworks.cruise.agent.AgentBootstrapper:101 - Launching Agent with command: D:\BuildTools\HarmonyGoProdAgent\jdk\jre\bin\java -Xms128m -Xmx256m "-DJAVA_SYS_MON_TEMP_DIR=D:\BuildTools\HarmonyGoProdAgent\tmp" -Dagent.binary.md5=dKqUVC2fvLstTHvB8Ag6MQ== -jar agent.jar https://im-go.mhf.mhc:8154/go/
DEBUG | wrapperp | 2014/07/08 12:48:15 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:15 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:15 | WrapperManager Debug: Send a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:15 | read a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:19 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:19 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:19 | WrapperManager Debug: Send a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:19 | read a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:24 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:24 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:24 | WrapperManager Debug: Send a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:24 | read a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:28 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:28 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:28 | WrapperManager Debug: Send a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:28 | read a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:33 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:33 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:33 | WrapperManager Debug: Send a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:33 | read a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:34 | send a packet SERVICE_CONTROL_CODE : 4
DEBUG | wrapper | 2014/07/08 12:48:34 | SERVICE_CONTROL_INTERROGATE
INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: Received a packet SERVICE_CONTROL_CODE : 4
INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: ServiceControlCode from Wrapper with code 4
DEBUG | wrapperp | 2014/07/08 12:48:34 | send a packet SERVICE_CONTROL_CODE : 4
DEBUG | wrapper | 2014/07/08 12:48:34 | SERVICE_CONTROL_INTERROGATE
INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: Received a packet SERVICE_CONTROL_CODE : 4
INFO | jvm 1 | 2014/07/08 12:48:34 | WrapperManager Debug: ServiceControlCode from Wrapper with code 4
DEBUG | wrapperp | 2014/07/08 12:48:37 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:37 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:37 | WrapperManager Debug: Send a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:37 | read a packet PING : ping
DEBUG | wrapperp | 2014/07/08 12:48:42 | send a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:42 | WrapperManager Debug: Received a packet PING : ping
INFO | jvm 1 | 2014/07/08 12:48:42 | WrapperManager Debug: Send a packet PING : ping
The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. McGraw Hill Financial reserves the right, subject to applicable local law, to monitor, review and process the content of any electronic message or information sent to or from McGraw Hill Financial e-mail addresses without informing the sender or recipient of the message. By sending electronic message or information to McGraw Hill Financial e-mail addresses you, as the sender, are consenting to McGraw Hill Financial processing any of your personal data therein.
|
|
From: Dannes W. <da...@ex...> - 2014-07-05 15:53:19
|
Hi, For some time now I have some issues to get my application started via the service wrapper during boot time of MacOSX ; the first issues appeared when I upgraded to Mountain Lion, it is still there with Mavericks; Upgrading to a more recent version of the wrapper did not help; I have been ignoring the issue for quite some time now, I think it is time to get grip on the issue right now :-) Some details The wrapper has been installed with the 'wrapper.sh install' command The application is started at system boot (the wrapper code writes to logfile, application writes logs too) but after some time there is a SigKill(9), see log files, application dies Some details worth to be mentioned: with 'wrapper.sh start' the application is always started without problems when started manually via launchctl the application always starts (so: the issue seems only to be present at startup time) under linux no issues have been reported My System: MacOSX 10.9.4 (server) Latest 64bit Java7 Java Service Wrapper Community Edition 64-bit 3.5.23 The .conf and .log files are attached; Please could you provide me some hints on what to change to get my application started again at every system reboot? I suspect that the Launchd terminates the service-wrapper, but I am not sure how to diagnose. Kind regards Dannes |
|
From: Leif M. <lei...@ta...> - 2014-07-02 03:26:37
|
Stephen, Your workarounds sound like good solutions. We are discussing this again internally. But are not yet sure of a good way to handle this. I will let you know if we figure something out. Cheers, Leif On Wed, Jul 2, 2014 at 1:21 AM, Stephen Slater <s.s...@ca...> wrote: > Leif, > > > > Thanks for your response. > > > > Having the wrapper shut the java server down during a JRE update then > restart again when finished would be a good solution for us. > > > > Our particular software tends to be used by one or a very small number of > users. While the client applet can be launched from any computer that can > see the server, it seems to be common that they run the client and server > on the same computer. What is happening is that customers are upgrading > their JRE when a new version comes out and it is failing because the server > is using it. They then phone us up saying they have upgraded Java and now > the software doesn’t work. So at the most basic, we need a change such > that if Java gets updated it does not break the system. > > > > I have discussed options with colleagues and what we are thinking of doing > unless someone suggests anything better quickly is (a) Switch to installing > our server with its own private copy of the JRE so it won’t block upgrading > the main copy. (b) Add an option to our client software to update the > server’s private copy of JRE from the main one (which would be user > initiated at a time to suit them). This would be done by client applet > telling server to do the update. Server would set off a new process on the > main copy of JRE. This would close down the wrapper, replace the private > copy of JRE with the main one, then restart the wrapper again. > > > > Regards, > > > > Stephen > > > > > > *From:* Leif Mortenson [mailto:lei...@ta...] > *Sent:* 01 July 2014 02:36 > *To:* Wrapper User List > *Subject:* Re: [Wrapper-user] What is the best way to handle JRE updates > on end user computers > > > > Stephen, > > Currently the Wrapper does not directly support this. > > What is the behavior that you are hoping to see? > > If a new JVM version is released, it will get downloaded and can be set to > run the installer automatically. > But when that happens, are you hoping that the Wrapper will shutdown the > JVM during the installer and then relaunch it? > > I have looked into this before, but have not yet figured out a reliable > way to detect if the installer is running efficiently. There are some > calls to detect when Windows is in the progress of installing something but > at that point it would already have started in the install and an error > would have been thrown by the installer. > > Once we have been able to detect that an installer is running, we would > have to decide if that installer even has anything to do with the JVM or > application being run by the Wrapper. Stopping the JVM for any and all > installers would cause its own set of problems. > > > > Even if we got this to work, it would need to be optional as auto upgrades > on any 24x7 server are risky. > 1) There is no guarantee that the new Java version will work correctly > with the application. > > 2) The timing of the JVM getting stopped and restarted would be controlled > by when the installer ran, this could cause problems for users of the > application if it was restarted at a strange time. > > We have also been thinking about ways to allow application upgrades and > even Wrapper upgrades as well. These also quickly have the same issues. > It appears to be possible for an installer to detect if some of the files > that it wants to install are in use, but not so much for the target > application to detect if it or its components are about to be reinstalled. > That appears to be why installers ask you to shutdown the target > application or forcibly do it themselves. > > Anything would of course need to be configurable so it could be disabled > for users that didn't want to use it. > > > > I'd appreciate any thoughts or suggestions anyone has on these issues. > > Cheers, > Leif > > > > On Tue, Jul 1, 2014 at 2:22 AM, Paul Gale <pau...@gm...> wrote: > > >We have considered including a separate version of JRE used only by our > service when our software is installed, so that the main JRE installation > used by browsers could be updated without the wrapper service interfering, > but our management considers this not acceptable because it would not get > updated with the latest JRE security fixes. > > Bundling the JRE is definitely gets my vote. If you made your application > auto-updating then that would handle the ability for your customers to > obtain timely security fixes. > > Any other kind of solution is ultimately a hack with all sorts of problems > that can arise not the least of which is that customers can install a JRE > that your application may not be compatible with. We had a similar > situation where users were upgrading JREs galore (which is not always what > you want) causing all manner of problems. Bundling the JRE would have fixed > that but we ended up switching to a web based application instead. Life has > been a lot easier since. > > > > On Mon, Jun 30, 2014 at 6:50 AM, Stephen Slater <s.s...@ca...> > wrote: > > (Re-submitted after subscribing to the mailing list) > > > > What is the best way to handle JRE updates on end user computers once a > service is up and running using the wrapper? > > > > When a new JRE update comes out, on running the installer, it notes that > “java.exe” is running and asks to stop this so that it can update java. If > I tell it to do this, the wrapper log shows “JVM exited unexpectedly” and > that it then automatically restarts it. The JRE update install then seems > to complete OK but has actually failed with browser plugins not added. > Restarting the computer does not fix this, and it is necessary to uninstall > the JRE and install it again to fix it. Until this is done Java client > applets run on the same computer are broken. > > > > If I manually stop the service while doing the JRE update then everything > goes fine, but if the software is installed on a customer’s computer it > would be highly preferable for automatic Java updates to go through without > them having to worry about stopping a service. > > > > We have considered including a separate version of JRE used only by our > service when our software is installed, so that the main JRE installation > used by browsers could be updated without the wrapper service interfering, > but our management considers this not acceptable because it would not get > updated with the latest JRE security fixes. We also considered using the > wrapper.restart.delay setting to delay restarts by 15 minutes to give the > JRE updater time to finish, but our management also declared this > unacceptable. > > > > What is the best way to deal with this? > > > > (We’re running version 3.2.3 by the way.) > > > > |
|
From: Stephen S. <s.s...@ca...> - 2014-07-01 16:22:00
|
Leif, Thanks for your response. Having the wrapper shut the java server down during a JRE update then restart again when finished would be a good solution for us. Our particular software tends to be used by one or a very small number of users. While the client applet can be launched from any computer that can see the server, it seems to be common that they run the client and server on the same computer. What is happening is that customers are upgrading their JRE when a new version comes out and it is failing because the server is using it. They then phone us up saying they have upgraded Java and now the software doesn’t work. So at the most basic, we need a change such that if Java gets updated it does not break the system. I have discussed options with colleagues and what we are thinking of doing unless someone suggests anything better quickly is (a) Switch to installing our server with its own private copy of the JRE so it won’t block upgrading the main copy. (b) Add an option to our client software to update the server’s private copy of JRE from the main one (which would be user initiated at a time to suit them). This would be done by client applet telling server to do the update. Server would set off a new process on the main copy of JRE. This would close down the wrapper, replace the private copy of JRE with the main one, then restart the wrapper again. Regards, Stephen From: Leif Mortenson [mailto:lei...@ta...] Sent: 01 July 2014 02:36 To: Wrapper User List Subject: Re: [Wrapper-user] What is the best way to handle JRE updates on end user computers Stephen, Currently the Wrapper does not directly support this. What is the behavior that you are hoping to see? If a new JVM version is released, it will get downloaded and can be set to run the installer automatically. But when that happens, are you hoping that the Wrapper will shutdown the JVM during the installer and then relaunch it? I have looked into this before, but have not yet figured out a reliable way to detect if the installer is running efficiently. There are some calls to detect when Windows is in the progress of installing something but at that point it would already have started in the install and an error would have been thrown by the installer. Once we have been able to detect that an installer is running, we would have to decide if that installer even has anything to do with the JVM or application being run by the Wrapper. Stopping the JVM for any and all installers would cause its own set of problems. Even if we got this to work, it would need to be optional as auto upgrades on any 24x7 server are risky. 1) There is no guarantee that the new Java version will work correctly with the application. 2) The timing of the JVM getting stopped and restarted would be controlled by when the installer ran, this could cause problems for users of the application if it was restarted at a strange time. We have also been thinking about ways to allow application upgrades and even Wrapper upgrades as well. These also quickly have the same issues. It appears to be possible for an installer to detect if some of the files that it wants to install are in use, but not so much for the target application to detect if it or its components are about to be reinstalled. That appears to be why installers ask you to shutdown the target application or forcibly do it themselves. Anything would of course need to be configurable so it could be disabled for users that didn't want to use it. I'd appreciate any thoughts or suggestions anyone has on these issues. Cheers, Leif On Tue, Jul 1, 2014 at 2:22 AM, Paul Gale <pau...@gm... <mailto:pau...@gm...> > wrote: >We have considered including a separate version of JRE used only by our service when our software is installed, so that the main JRE installation used by browsers could be updated without the wrapper service interfering, but our management considers this not acceptable because it would not get updated with the latest JRE security fixes. Bundling the JRE is definitely gets my vote. If you made your application auto-updating then that would handle the ability for your customers to obtain timely security fixes. Any other kind of solution is ultimately a hack with all sorts of problems that can arise not the least of which is that customers can install a JRE that your application may not be compatible with. We had a similar situation where users were upgrading JREs galore (which is not always what you want) causing all manner of problems. Bundling the JRE would have fixed that but we ended up switching to a web based application instead. Life has been a lot easier since. On Mon, Jun 30, 2014 at 6:50 AM, Stephen Slater <s.s...@ca... <mailto:s.s...@ca...> > wrote: (Re-submitted after subscribing to the mailing list) What is the best way to handle JRE updates on end user computers once a service is up and running using the wrapper? When a new JRE update comes out, on running the installer, it notes that “java.exe” is running and asks to stop this so that it can update java. If I tell it to do this, the wrapper log shows “JVM exited unexpectedly” and that it then automatically restarts it. The JRE update install then seems to complete OK but has actually failed with browser plugins not added. Restarting the computer does not fix this, and it is necessary to uninstall the JRE and install it again to fix it. Until this is done Java client applets run on the same computer are broken. If I manually stop the service while doing the JRE update then everything goes fine, but if the software is installed on a customer’s computer it would be highly preferable for automatic Java updates to go through without them having to worry about stopping a service. We have considered including a separate version of JRE used only by our service when our software is installed, so that the main JRE installation used by browsers could be updated without the wrapper service interfering, but our management considers this not acceptable because it would not get updated with the latest JRE security fixes. We also considered using the wrapper.restart.delay setting to delay restarts by 15 minutes to give the JRE updater time to finish, but our management also declared this unacceptable. What is the best way to deal with this? (We’re running version 3.2.3 by the way.) |
|
From: Leif M. <lei...@ta...> - 2014-07-01 01:36:04
|
Stephen, Currently the Wrapper does not directly support this. What is the behavior that you are hoping to see? If a new JVM version is released, it will get downloaded and can be set to run the installer automatically. But when that happens, are you hoping that the Wrapper will shutdown the JVM during the installer and then relaunch it? I have looked into this before, but have not yet figured out a reliable way to detect if the installer is running efficiently. There are some calls to detect when Windows is in the progress of installing something but at that point it would already have started in the install and an error would have been thrown by the installer. Once we have been able to detect that an installer is running, we would have to decide if that installer even has anything to do with the JVM or application being run by the Wrapper. Stopping the JVM for any and all installers would cause its own set of problems. Even if we got this to work, it would need to be optional as auto upgrades on any 24x7 server are risky. 1) There is no guarantee that the new Java version will work correctly with the application. 2) The timing of the JVM getting stopped and restarted would be controlled by when the installer ran, this could cause problems for users of the application if it was restarted at a strange time. We have also been thinking about ways to allow application upgrades and even Wrapper upgrades as well. These also quickly have the same issues. It appears to be possible for an installer to detect if some of the files that it wants to install are in use, but not so much for the target application to detect if it or its components are about to be reinstalled. That appears to be why installers ask you to shutdown the target application or forcibly do it themselves. Anything would of course need to be configurable so it could be disabled for users that didn't want to use it. I'd appreciate any thoughts or suggestions anyone has on these issues. Cheers, Leif On Tue, Jul 1, 2014 at 2:22 AM, Paul Gale <pau...@gm...> wrote: > >We have considered including a separate version of JRE used only by our > service when our software is installed, so that the main JRE installation > used by browsers could be updated without the wrapper service interfering, > but our management considers this not acceptable because it would not get > updated with the latest JRE security fixes. > > Bundling the JRE is definitely gets my vote. If you made your application > auto-updating then that would handle the ability for your customers to > obtain timely security fixes. > > Any other kind of solution is ultimately a hack with all sorts of problems > that can arise not the least of which is that customers can install a JRE > that your application may not be compatible with. We had a similar > situation where users were upgrading JREs galore (which is not always what > you want) causing all manner of problems. Bundling the JRE would have fixed > that but we ended up switching to a web based application instead. Life has > been a lot easier since. > > > On Mon, Jun 30, 2014 at 6:50 AM, Stephen Slater <s.s...@ca...> > wrote: > >> (Re-submitted after subscribing to the mailing list) >> >> >> >> What is the best way to handle JRE updates on end user computers once a >> service is up and running using the wrapper? >> >> >> >> When a new JRE update comes out, on running the installer, it notes that >> “java.exe” is running and asks to stop this so that it can update java. If >> I tell it to do this, the wrapper log shows “JVM exited unexpectedly” and >> that it then automatically restarts it. The JRE update install then seems >> to complete OK but has actually failed with browser plugins not added. >> Restarting the computer does not fix this, and it is necessary to uninstall >> the JRE and install it again to fix it. Until this is done Java client >> applets run on the same computer are broken. >> >> >> >> If I manually stop the service while doing the JRE update then everything >> goes fine, but if the software is installed on a customer’s computer it >> would be highly preferable for automatic Java updates to go through without >> them having to worry about stopping a service. >> >> >> >> We have considered including a separate version of JRE used only by our >> service when our software is installed, so that the main JRE installation >> used by browsers could be updated without the wrapper service interfering, >> but our management considers this not acceptable because it would not get >> updated with the latest JRE security fixes. We also considered using the >> wrapper.restart.delay setting to delay restarts by 15 minutes to give the >> JRE updater time to finish, but our management also declared this >> unacceptable. >> >> >> >> What is the best way to deal with this? >> >> >> >> (We’re running version 3.2.3 by the way.) >> >> |
|
From: Paul G. <pau...@gm...> - 2014-06-30 17:22:39
|
>We have considered including a separate version of JRE used only by our service when our software is installed, so that the main JRE installation used by browsers could be updated without the wrapper service interfering, but our management considers this not acceptable because it would not get updated with the latest JRE security fixes. Bundling the JRE is definitely gets my vote. If you made your application auto-updating then that would handle the ability for your customers to obtain timely security fixes. Any other kind of solution is ultimately a hack with all sorts of problems that can arise not the least of which is that customers can install a JRE that your application may not be compatible with. We had a similar situation where users were upgrading JREs galore (which is not always what you want) causing all manner of problems. Bundling the JRE would have fixed that but we ended up switching to a web based application instead. Life has been a lot easier since. On Mon, Jun 30, 2014 at 6:50 AM, Stephen Slater <s.s...@ca...> wrote: > (Re-submitted after subscribing to the mailing list) > > > > What is the best way to handle JRE updates on end user computers once a > service is up and running using the wrapper? > > > > When a new JRE update comes out, on running the installer, it notes that > “java.exe” is running and asks to stop this so that it can update java. If > I tell it to do this, the wrapper log shows “JVM exited unexpectedly” and > that it then automatically restarts it. The JRE update install then seems > to complete OK but has actually failed with browser plugins not added. > Restarting the computer does not fix this, and it is necessary to uninstall > the JRE and install it again to fix it. Until this is done Java client > applets run on the same computer are broken. > > > > If I manually stop the service while doing the JRE update then everything > goes fine, but if the software is installed on a customer’s computer it > would be highly preferable for automatic Java updates to go through without > them having to worry about stopping a service. > > > > We have considered including a separate version of JRE used only by our > service when our software is installed, so that the main JRE installation > used by browsers could be updated without the wrapper service interfering, > but our management considers this not acceptable because it would not get > updated with the latest JRE security fixes. We also considered using the > wrapper.restart.delay setting to delay restarts by 15 minutes to give the > JRE updater time to finish, but our management also declared this > unacceptable. > > > > What is the best way to deal with this? > > > > (We’re running version 3.2.3 by the way.) > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Stephen S. <s.s...@ca...> - 2014-06-30 10:50:51
|
(Re-submitted after subscribing to the mailing list) What is the best way to handle JRE updates on end user computers once a service is up and running using the wrapper? When a new JRE update comes out, on running the installer, it notes that "java.exe" is running and asks to stop this so that it can update java. If I tell it to do this, the wrapper log shows "JVM exited unexpectedly" and that it then automatically restarts it. The JRE update install then seems to complete OK but has actually failed with browser plugins not added. Restarting the computer does not fix this, and it is necessary to uninstall the JRE and install it again to fix it. Until this is done Java client applets run on the same computer are broken. If I manually stop the service while doing the JRE update then everything goes fine, but if the software is installed on a customer's computer it would be highly preferable for automatic Java updates to go through without them having to worry about stopping a service. We have considered including a separate version of JRE used only by our service when our software is installed, so that the main JRE installation used by browsers could be updated without the wrapper service interfering, but our management considers this not acceptable because it would not get updated with the latest JRE security fixes. We also considered using the wrapper.restart.delay setting to delay restarts by 15 minutes to give the JRE updater time to finish, but our management also declared this unacceptable. What is the best way to deal with this? (We're running version 3.2.3 by the way.) |
|
From: Matthew S. <mat...@ta...> - 2014-06-16 07:15:06
|
Hello everyone, We are proud to announce the release of version 3.5.25 of the Java Service Wrapper. http://wrapper.tanukisoftware.org/doc/english/download.jsp Most notably we fixed a problem on AIX which caused crashes or deadlocks on startup for some users. This had been an issue since 3.5.0 but only reported recently. You can review the release notes for a full list of changes here: http://wrapper.tanukisoftware.org/doc/english/release-notes.html As always, please let us know how we can continue to improve the Java Service Wrapper to meet your needs. Sincerely, Matthew Scott Tanuki Software, Ltd. http://www.tanukisoftware.com |
|
From: <bri...@we...> - 2014-06-06 15:01:26
|
Thank you so much, Leif and Alexandre for your help in getting me past this hurdle. And thanks for updating the documentation on this issue for future developers! ☺
Thanks.
~ Brian ~
From: Leif Mortenson [mailto:lei...@ta...]
Sent: Friday, June 06, 2014 2:20 AM
To: Wrapper User List
Subject: Re: [Wrapper-user] Issue with setting service account password when using Tanuki JSW
Brian,
Just following up the list as the end of our conversation was off list.
The problem ended up being because the password used contained a '#' character.
wrapper.ntservice.password=12345#7890
When the Wrapper reads in any property, it treats a '#' as a comment so all the Wrapper was seeing was this:
wrapper.ntservice.password=12345
We have made a note in the documentation that will be in the next site update.
If you need to use a password conaining a '#' then you will need to double up the character so it escapes itself as follows:
wrapper.ntservice.password=12345##7890
Cheers,
Leif
On Mon, Jun 2, 2014 at 11:36 PM, <bri...@we...<mailto:bri...@we...>> wrote:
Hi Alexandre,
Sorry for the delay in response.
Yes, AD-ENT\2CES-SERVICES-ID is an administrator on the machine with "Log on as a service" rights.
I will set the debug statement in the .conf file and send you the results as requested.
A few things to note:
• I have removed the actual password value from the config file for security purposes
• Although getting the “wrapper.ntservice.password={Password}” property to work would be good, my ultimate goal is to use the “#include ..\conf\password.conf” property. (Neither of these work for me currently)
• I am including 2 log files that have been written to. (I left all entries in these files, including installations from 5/9/2014, just FYI):
1. wrapper.log
• You can see from earlier wrapper.log entries from 5/9/2014 where I tried the include file method for entering the password during service installation. The log indicates that the include file is read in properly
• Then there are the remaining entries from 2014/05/09, 2014/05/15, and 2014/06/02 where I tried installing the service using the “wrapper.ntservice.password={Password}” property.
2. CESCopyUtility_ServiceWrapper.log
• You can see from the CESCopyUtility_ServiceWrapper.log – beginning with the first 2014/05/09 09:59:38 entry and ending with the 2014/05/09 10:34:52 entry – that the service ran successfully twice when I used the “wrapper.ntservice.account.prompt=true” property to install the service.
• Then from 2014/05/09 12:08:01 on, there are multiple install/uninstall sequences where I tried installing the service using the “wrapper.ntservice.password={Password}” property, but afterwards, the service execution would fail with the error message I showed as a screen print in the original email.
Please let me know if you need more info or data.
Thanks.
~ Brian ~
From: Alexandre Klein [mailto:ale...@ta...<mailto:ale...@ta...>]
Sent: Wednesday, May 28, 2014 11:21 PM
To: wra...@li...<mailto:wra...@li...>
Subject: Re: [Wrapper-user] Issue with setting service account password when using Tanuki JSW
Hi Brian,
1. Sorry for my mistake.
wrapper.ntservice.* is the correct name.
2. Is “AD-ENT\2CES-SERVICES-ID” an admin?
With which user are you installing and running the Wrapper? Is this user an admin?
This user has the correct right in "log on as a service" in the "Local Security Settings" window?
3. You can place the property anywhere.
Can you add in wrapper.conf:
wrapper.debug=TRUE
And try again, then send me your configuration file wrapper.conf and your log file wrapper.log.
Please use our support email: su...@ta...<mailto:su...@ta...>
I'm using Windows Server 2003 (32bit) for my test and everything look fine.
Regards,
Alexandre Klein
On Wed, May 28, 2014 at 11:30 PM, <bri...@we...<mailto:bri...@we...>> wrote:
Hi Alexandre,
Thanks for the response!
1. I have actually tried this before, but I did notice a difference in what you have below and what I have tried:
You have: wrapper.netservice.account, wrapper.netservice.password
I have: wrapper.ntservice.account, wrapper.ntservice.password
Should I be using netservice instead of ntservice? (BTW, this is being installed on a machine with Windows Server 2003 Enterprise x64 OS, if it matters).
2. Something else: I notice that the wrapper.ntservice.account={account ID} property seems to work. (i.e., as you can see from the original 2nd screen print, “AD-ENT\2CES-SERVICES-ID” is what is stored in the Service Control Manager, which is correct). If I was to use the interactive option (i.e., “wrapper.ntservice.account.prompt=true”), and enter the password from the command line during installation, the correct password is stored and the service runs fine, but this is the only password-setting property I can get to work. ☹
3. Lastly, if I am going to use the “wrapper.ntservice.password” property, does the order/location in the wrapper.conf file where I place this property matter?
Thanks.
~ Brian ~
From: Alexandre Klein [mailto:ale...@ta...<mailto:ale...@ta...>]
Sent: Wednesday, May 28, 2014 2:46 AM
To: wra...@li...<mailto:wra...@li...>
Subject: Re: [Wrapper-user] Issue with setting service account password when using Tanuki JSW
Brian,
Sorry for the delay.
The property “wrapper.ntservice.password={Password}” is used when the service is installed and it is stored in the Service Control Manager.
When the Wrapper starts the service, it doesn't use “wrapper.ntservice.password"! So it is important to set this property correctly when you install the service.
Maybe when you installed the service, the password was not correct?
Can you do this test:
- uninstall the service
- set the login and password (wrapper.netservice.account, wrapper.netservice.password) in wrapper.conf
- install the service
- start the Wrapper
Then it should work.
Please try this and let me know the result.
Regards,
Alexandre Klein
On Fri, May 16, 2014 at 2:20 AM, <bri...@we...<mailto:bri...@we...>> wrote:
Hello,
I am currently using “wrapper-windows-x86-32-3.5.24” to install a Java service on a Windows Server 2003 Enterprise x64 SP2 machine. I am having problem with the entering the password for the service account under which this service will run.
For some reason, the only way I can get the password to store correctly and a subsequent successful service execution, is to require interaction from the user (i.e., have them manually enter the password) using the “wrapper.ntservice.account.prompt=true” option.
If I try either the “wrapper.ntservice.password={Password}” setting or the include file setting (i.e., “#include ..\conf\password.conf”), the service is installed and attempts to run under the proper account name, but fails due to a password violation.
|
|
From: Leif M. <lei...@ta...> - 2014-06-06 09:04:37
|
Tue, The wrapper.successful_invocation_time property lets you define how many seconds a JVM needs to be running before the failed invocation count is reset. The wrapper.max_failed_invocations property then controls how many times the Wrapper will try to restart the JVM before giving up and shutting down. http://wrapper.tanukisoftware.com/doc/english/prop-max-failed-invocations.html http://wrapper.tanukisoftware.com/doc/english/prop-successful-invocation-time.html I guess it would be possible to use these to restart the JVM several times waiting for your other process to complete. The problem though is that JVMs are pretty resource intensive when they are starting up. The idea using the jvm_prelaunch event would let you avoid the extra restarts by waiting for your process to complete. Let us know what you end up doing. Cheers, Leif On Thu, Jun 5, 2014 at 9:28 PM, Tue S. Dissing <TS...@cd...> wrote: > Thanks, but not 100% what I was looking for. > > > > > > Gave me another idea though. > > > > What if I set both failed_invocation_time and fail_invocations to 5. > > Is there some way to pause the wrapper let’s say 10 minutes and reset the > failed_invocations? > > > > > > Best regards > > > > *Tue S. Dissing* > > > > *From:* Leif Mortenson [mailto:lei...@ta...] > *Sent:* 5. juni 2014 10:58 > *To:* Wrapper User List > *Subject:* Re: [Wrapper-user] Is it possible to have a dynamically > defined restart delay? > > > > Tue, > Another option that I just thought of requires the Professional Edition > but should work smoothly. You can give it a try with a free Trial license. > > Register a command to be executed in response to the "jvm_prelaunch" event > and set it up to block until complete. > You can then run your external script and the Wrapper will wait for it to > complete before launching the new JVM. > This would happen automatically on startup and whenever you restarted the > JVM. > > It would look something like this in your wrapper.conf: > wrapper.event.jvm_prelaunch.command.argv.1=MyJob.bat > wrapper.event.jvm_prelaunch.command.block=TRUE > > You can also set it up to have a block timeout, control what to do if the > that timeout takes place, and perform a different action if the batch > script returns specific error codes. > > Cheers, > Leif > > > > > > On Thu, Jun 5, 2014 at 5:52 PM, Leif Mortenson < > lei...@ta...> wrote: > > Tue, > The restart delay itself can't be changed in that way because it sounds > like you are actually not sure how long it will take. > > Maybe a better solution is to put the Wrapper into a Paused state: > http://wrapper.tanukisoftware.com/doc/english/prop-pausable.html > > There is then a number of ways to resume the Wrapper and thus start your > application. > * Command File and the RESUME command: > http://wrapper.tanukisoftware.com/doc/english/prop-commandfile.html > > > * Resume the service using service manager or command line > > * Using a timer and RESUME action: > http://wrapper.tanukisoftware.com/doc/english/prop-timer-n.html#action > > If you use the Pause / Resume method, you will have to make sure that the > Wrapper is reliably resumed in all cases. > > If you use a timer to resume every minute for example, you could have your > Java code immediately repause it and stop the JVM if some condition is not > met. > > You could also use the timer to run every 15 mintues or something in the > same way as a last resort in case the normal resume fails to be fired. > > Normally you could run your external job and then use "net resume myapp" > at the end to resume the Wrapper. > > Please let me know how this works for you. > > > > Cheers, > Leif > > > > > > On Thu, Jun 5, 2014 at 5:11 PM, Tue S. Dissing <TS...@cd...> wrote: > > Hi, > > > > We’re running with a lot of simultaneous jobs each processing its own > thing. > > Each run with its own wrapper configuration. > > > > We have no control over how busy these processes are, but we would like to > get tasks processed as soon as they tick in – i.e. we have no can control > over the amount of work coming in. > > > > So I’m looking for a way to dynamically defining the restart delay. > > > > > > Let’s say our jobs run every 60 seconds, then I would like to increase the > delay to say 5 minutes for individual jobs if their processing time is > below a certain threshold; i.e. if it only run for 5 sec. > > > > The reason for this is that we’re seeing a heavy load on the CPU when all > these jobs starts and stops all the time (and fires up the JVM which then, > in vain, looks for new records to process)– we do not process much data but > the CPU load is close to 90% at all time. > > > > Any other suggestion that might help us with this problem is more than > welcome. > > > > Best regards > > > > *Tue S. Dissing* > > Technical Lead > > > |
|
From: Leif M. <lei...@ta...> - 2014-06-06 06:19:59
|
Brian,
Just following up the list as the end of our conversation was off list.
The problem ended up being because the password used contained a '#'
character.
wrapper.ntservice.password=12345#7890
When the Wrapper reads in any property, it treats a '#' as a comment so all
the Wrapper was seeing was this:
wrapper.ntservice.password=12345
We have made a note in the documentation that will be in the next site
update.
If you need to use a password conaining a '#' then you will need to double
up the character so it escapes itself as follows:
wrapper.ntservice.password=12345##7890
Cheers,
Leif
On Mon, Jun 2, 2014 at 11:36 PM, <bri...@we...> wrote:
> Hi Alexandre,
>
>
>
> Sorry for the delay in response.
>
>
>
> Yes, AD-ENT\2CES-SERVICES-ID is an administrator on the machine with "Log
> on as a service" rights.
>
>
>
> I will set the debug statement in the .conf file and send you the results
> as requested.
>
>
>
> A few things to note:
>
> · I have removed the actual password value from the config file
> for security purposes
>
> · Although getting the “wrapper.ntservice.password={Password}”
> property to work would be good, my ultimate goal is to use the “#include
> ..\conf\password.conf” property. (Neither of these work for me currently)
>
> · I am including 2 log files that have been written to. (I left
> all entries in these files, including installations from 5/9/2014, just
> FYI):
>
> 1. wrapper.log
>
> § You can see from earlier wrapper.log entries from 5/9/2014 where I
> tried the include file method for entering the password during service
> installation. The log indicates that the include file is read in properly
>
> § Then there are the remaining entries from 2014/05/09, 2014/05/15, and
> 2014/06/02 where I tried installing the service using the
> “wrapper.ntservice.password={Password}” property.
>
> 2. CESCopyUtility_ServiceWrapper.log
>
> § You can see from the CESCopyUtility_ServiceWrapper.log – beginning
> with the first 2014/05/09 09:59:38 entry and ending with the 2014/05/09
> 10:34:52 entry – that the service ran successfully twice when I used the
> “wrapper.ntservice.account.prompt=true” property to install the service.
>
> § Then from 2014/05/09 12:08:01 on, there are multiple install/uninstall
> sequences where I tried installing the service using the
> “wrapper.ntservice.password={Password}” property, but afterwards, the
> service execution would fail with the error message I showed as a screen
> print in the original email.
>
>
>
> Please let me know if you need more info or data.
>
>
>
> Thanks.
>
>
>
> *~ Brian ~*
>
>
>
> *From:* Alexandre Klein [mailto:ale...@ta...]
> *Sent:* Wednesday, May 28, 2014 11:21 PM
>
> *To:* wra...@li...
> *Subject:* Re: [Wrapper-user] Issue with setting service account password
> when using Tanuki JSW
>
>
>
> Hi Brian,
>
> 1. Sorry for my mistake.
> wrapper.ntservice.* is the correct name.
>
> 2. Is “AD-ENT\2CES-SERVICES-ID” an admin?
>
> With which user are you installing and running the Wrapper? Is this user
> an admin?
>
> This user has the correct right in "log on as a service" in the "Local
> Security Settings" window?
>
>
>
> 3. You can place the property anywhere.
>
>
>
> Can you add in wrapper.conf:
>
> wrapper.debug=TRUE
>
>
>
> And try again, then send me your configuration file wrapper.conf and your
> log file wrapper.log.
>
> Please use our support email: su...@ta...
>
>
>
> I'm using Windows Server 2003 (32bit) for my test and everything look
> fine.
>
>
>
> Regards,
>
> Alexandre Klein
>
>
> On Wed, May 28, 2014 at 11:30 PM, <bri...@we...> wrote:
>
> Hi Alexandre,
>
>
>
> Thanks for the response!
>
>
>
> 1. I have actually tried this before, but I did notice a difference
> in what you have below and what I have tried:
>
>
>
> You have: wrapper.*net*service.account, wrapper.*net*
> service.password
>
> I have: wrapper.*nt*service.account, wrapper.*nt*
> service.password
>
>
>
> Should I be using *net*service instead of *nt*service? (BTW, this is
> being installed on a machine with Windows Server 2003 Enterprise x64 OS, if
> it matters).
>
>
>
> 2. Something else: I notice that the wrapper.ntservice.account=*{account
> ID}* property seems to work. (i.e., as you can see from the original 2nd
> screen print, “AD-ENT\2CES-SERVICES-ID” is what is stored in the Service
> Control Manager, which is correct). If I was to use the interactive option
> (i.e., “wrapper.ntservice.account.prompt=true”), and enter the password
> from the command line during installation, the correct password is stored
> and the service runs fine, but this is the only password-setting property I
> can get to work. L
>
>
>
> 3. Lastly, if I am going to use the “wrapper.ntservice.password”
> property, does the order/location in the wrapper.conf file where I place
> this property matter?
>
>
>
> Thanks.
>
>
>
> *~ Brian ~*
>
>
>
> *From:* Alexandre Klein [mailto:ale...@ta...]
> *Sent:* Wednesday, May 28, 2014 2:46 AM
> *To:* wra...@li...
> *Subject:* Re: [Wrapper-user] Issue with setting service account password
> when using Tanuki JSW
>
>
>
> Brian,
>
>
>
> Sorry for the delay.
>
>
>
> The property “wrapper.ntservice.password=*{Password}*” is used when the
> service is installed and it is stored in the Service Control Manager.
>
> When the Wrapper starts the service, it doesn't use
> “wrapper.ntservice.password"! So it is important to set this property
> correctly when you install the service.
>
>
>
> Maybe when you installed the service, the password was not correct?
>
>
>
> Can you do this test:
>
> - uninstall the service
>
> - set the login and password (wrapper.netservice.account,
> wrapper.netservice.password) in wrapper.conf
>
> - install the service
>
> - start the Wrapper
>
>
>
> Then it should work.
>
> Please try this and let me know the result.
>
>
>
> Regards,
>
> Alexandre Klein
>
>
>
> On Fri, May 16, 2014 at 2:20 AM, <bri...@we...> wrote:
>
> Hello,
>
>
>
> I am currently using “wrapper-windows-x86-32-3.5.24” to install a Java
> service on a Windows Server 2003 Enterprise x64 SP2 machine. I am having
> problem with the entering the password for the service account under which
> this service will run.
>
>
>
> For some reason, the only way I can get the password to store correctly
> and a subsequent successful service execution, is to require interaction
> from the user (i.e., have them manually enter the password) using the
> “wrapper.ntservice.account.prompt=true” option.
>
>
>
> If I try either the “wrapper.ntservice.password=*{Password}*” setting or
> the include file setting (i.e., “#include ..\conf\password.conf”), the
> service is installed and attempts to run under the proper account name, but
> fails due to a password violation.
>
>
>
>
|
165 messages has been excluded from this view by a project administrator.
