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: Scott H. <sd...@gm...> - 2007-12-31 08:41:31
|
Marcelo, did you finally succeed in getting the wrapper to work on Solaris
x64? I've gotten it to compile, but it won't load the native library:
WARNING - Unable to load the Wrapper's native library 'libwrapper.so '.
The file is located on the path at the following location but
could not be loaded:
/export/home/sdhays/Desktop/tmp/wrapper_3.2.3_src-64/bin/../lib/libwrapper.so
Please verify that the file is readable by the current user
and that the file has not been corrupted in any way.
One common cause of this problem is running a 32-bit version
of the Wrapper with a 64-bit version of Java, or vica versa.
This is a 64-bit JVM.
Reported cause:
/export/home/sdhays/Desktop/tmp/wrapper_3.2.3_src-64/lib/libwrapper.so:
ld.so.1: java: fatal: relocation error: R_AMD64_PC32: file
/export/home/sdhays/Desktop/tmp/wrapper_3.2.3_src-64/lib/libwrapper.so:
symbol main: value 0x280023eff84 does not fit
System signals will not be handled correctly.
I haven't figured out how to fix this; most of the things I find concerning
this error on the internet use the Sun Studio compiler, which I have also
tried and get the same result, even after specifying -KPIC (the most common
suggestion) and -xarch=amd64 -xmodel=medium.
Any suggestions?
Scott
|
|
From: Dittmar G. <gr...@if...> - 2007-12-27 19:51:51
|
Dittmar Gross ist wegen Urlaub bis 28-Dez-2007 nicht per eMail zu erreichen. Bitte wenden Sie sich in dringenden Faellen an Telefon +49 (69) 7680 50, Telefax +49 (69) 7680 5333 oder eMail fi...@if... Dittmar Gross is not available via eMail until Dec-28-2007 because of vacation. In urgent cases please contact us directly by Telephone +49 (69) 7680 50, Fax +49 (69) 7680 5333 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: Stirling C. <sc...@al...> - 2007-12-27 19:50:48
|
Hi, =20 I=92m new to the open source process, so please bear with me if this = question is silly. After a few modifications to the makefiles, I=92ve = successfully compiled the wrapper for HP-UX Itanium 64-bit and it = appears to be functioning correctly. I=92d like to make the binary = available to other wrapper users=85 is this permissible and/or = desirable? If so, what is the process to make it available from = SourceForge? =20 Cheers, =20 =20 Stirling Chow, Senior Software Developer AlarmPoint Systems, Inc. (250) 380-0304 =20 Read More About AlarmPoint Systems: =20 HYPERLINK = "http://www.alarmpoint.com/?&SID=3Dnews&pageID=3Dpress.cfm§ion=3Ddeta= il&article_ID=3D85"AlarmPoint Releases Powerful New Enterprise Features = with AlarmPoint 3.1 HYPERLINK = "http://www.alarmpoint.com/?&SID=3Dnews&pageID=3Dpress.cfm§ion=3Ddeta= il&article_ID=3D84"AlarmPoint Delivers 64 Percent Growth, Exceeds = Expectations for Sixth Consecutive Quarter =20 No virus found in this outgoing message. Checked by AVG Free Edition.=20 Version: 7.5.516 / Virus Database: 269.17.11/1200 - Release Date: = 27/12/2007 1:34 PM =20 |
|
From: Barry A. <tit...@gm...> - 2007-12-21 14:19:02
|
Thanks for the info Leif. I think this is what I am looking for. Would a normal User be able to communicate with a service running under Admin? I know that a normal User cannot stop/start/pause a service so I would think it's also a problem to communicate any special event. thanks, -B On Dec 21, 2007 12:35 AM, Leif Mortenson <le...@ta...> wrote: > Barry, > It depends on exactly what it is that you want to trigger. > Is it a life cycle action of the Wrapper to to start a piece of > arbitrary code in your server. > > I assume the later. > > 1) The Wrapper allows you to capture and react to user defined > service control codes by registering a WrapperEventListener > using the following method call: > WrapperManager.addWrapperEventListener(l, > WrapperEventListener.EVENT_FLAG_SERVICE); > Your listener will then receive WrapperServiceControlEvents > whenever your service receives any control code, including user > codes. > The drawback here is with the ability to easily send those > custom codes. Do you know of a way to do it from the command > prompt? > > 2) The way I have done it in the past is to use the WrapperActionServer > class. This creates a very simple telnet server which receives one > character commands and then immediately closes the connections. > It comes with a number of predefined commands, but you can also > register your own using the registerAction method which takes the > trigger character and a Runnable instance. > A sample code fragment can be found in the javadocs for > WrapperActionServer. > > This solution works nicely as you can control it from anywhere > by simply using a telnet client. The drawback is that it is not very > secure as currently implemented. That could be resolved by adding > Passwords, IP masks etc, but it is not in there at the moment. > > See the javadocs for documentation on all of the above: > http://wrapper.tanukisoftware.org/doc/english/javadocs.html > > Cheers, > Leif > > Barry Andrews wrote: > > Hi All, > > > > I am in the process of evaluating Java Service Wrapper for Windows and I > > am wondering if there is a built in way to communicate to a wrapped > > service? > > > > I have some code that I need to run as a Windows service and I need to > > be able to communicate to it from another process and tell it to run. On > > Windows you have you have the ServiceBase.OnCustomCommand listener. > > > > I have thought about different ways to communicate this event to the > > service. One way is programmatically pausing the service, ( "net pause > > <service name>" ) and continuing it when I need it to run. The problem > > with this is it needs to work for someone logged in as a regular "User", > > not just an admin. The service would have admin privileges, but the > > program may only have User privileges. > > > > I also thought about communicating via ports, but I didn't know if there > > was some communication functionality already built in that I was just > > overlooking? Any thoughts on this? > > > > Many thanks to you all. > > > > -B > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Leif M. <le...@ta...> - 2007-12-21 08:21:14
|
Markus, The test was done on Windows XP and is included with the wrapper source as the test\TestShutdownHook.bat test It works by default where the jvm_exit timeout will expire and kill the JVM. You need to modify the test\shutdownhook.conf configuration file and add the property wrapper.jvm_exit.timeout=60 property to make sure the shutdown hook has time to complete. I know you don't have the ability to build the wrapper so I'll email you a distribution containing the test directory directly. Cheers, Leif Markus Schlegel wrote: > How did you do your testcase? What OS do you use? > Could you send me your test-app in order that I could test if it > works the same on our systems? > > Markus > > 2007/12/21, Leif Mortenson < le...@ta... > <mailto:le...@ta...>>: > > Markus, > I went back today and retested how shutdown hooks work with the > Wrapper today. > > This is the end of the debug log output for a shutdown hook which > takes longer to run than the configured jvm_exit timeout. Note > that the WrapperManager's internal shutdown hook completes > promptly, but the JVM does not actually terminate because the > custom shutdown hook is still running: > --- > DEBUG | wrapperp | 2007/12/21 10:43:46 | read a packet STOP : 0 > DEBUG | wrapper | 2007/12/21 10:43:46 | JVM requested a > shutdown. (0) > DEBUG | wrapper | 2007/12/21 10:43:46 | wrapperStopProcess(0) > called. > DEBUG | wrapper | 2007/12/21 10:43:46 | Sending stop signal to JVM > DEBUG | wrapperp | 2007/12/21 10:43:46 | send a packet STOP : NULL > INFO | jvm 1 | 2007/12/21 10:43:46 | WrapperManager Debug: > Received > a packet STOP : > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: > Thread, > Wrapper-Shutdown-Hook, handling the shutdown process. > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: > calling > listener.stop() > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperSimpleApp Debug: > stop(0) > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: > returned > from listener.stop() -> 0 > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: > shutdownJVM(0) Thread:Wrapper-Shutdown-Hook > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: Send a > packet STOPPED : 0 > DEBUG | wrapperp | 2007/12/21 10:43:47 | read a packet STOPPED : 0 > DEBUG | wrapper | 2007/12/21 10:43:47 | JVM signalled that it > was stopped. > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: > Closing > socket. > DEBUG | wrapperp | 2007/12/21 10:43:48 | socket read no code > (closed?). > DEBUG | wrapperp | 2007/12/21 10:43:48 | server listening on port > 32001. > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: > ShutdownHook complete > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: Server > daemon shut down > ERROR | wrapper | 2007/12/21 10:44:06 | Shutdown failed: Timed out > waiting for the JVM to terminate. > ERROR | wrapper | 2007/12/21 10:44:07 | JVM did not exit on request, > terminated > DEBUG | wrapper | 2007/12/21 10:44:07 | Signal trapped. Details: > DEBUG | wrapper | 2007/12/21 10:44:07 | signal number=17 > (SIGCHLD), > source="unknown" > DEBUG | wrapper | 2007/12/21 10:44:07 | Received SIGCHLD, > checking JVM > process status. > STATUS | wrapper | 2007/12/21 10:44:07 | JVM received a signal > SIGKILL (9). > STATUS | wrapper | 2007/12/21 10:44:07 | <-- Wrapper Stopped > --- > > For this next run, I have extended the jvm_exit timeout long > enough to allow the custom shutdown hook to complete. It looks > pretty much the same as the last example except that shutdown > completes. > --- > DEBUG | wrapperp | 2007/12/21 11:00:42 | read a packet STOP : 0 > DEBUG | wrapper | 2007/12/21 11:00:42 | JVM requested a > shutdown. (0) > DEBUG | wrapper | 2007/12/21 11:00:42 | wrapperStopProcess(0) > called. > DEBUG | wrapper | 2007/12/21 11:00:42 | Sending stop signal to JVM > DEBUG | wrapperp | 2007/12/21 11:00:42 | send a packet STOP : NULL > INFO | jvm 1 | 2007/12/21 11:00:42 | WrapperManager Debug: > Received > a packet STOP : > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: > Thread, > Wrapper-Shutdown-Hook, handling the shutdown process. > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: > calling > listener.stop() > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperSimpleApp Debug: > stop(0) > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: > returned > from listener.stop() -> 0 > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: > shutdownJVM(0) Thread:Wrapper-Shutdown-Hook > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: Send a > packet STOPPED : 0 > DEBUG | wrapperp | 2007/12/21 11:00:43 | read a packet STOPPED : 0 > DEBUG | wrapper | 2007/12/21 11:00:43 | JVM signalled that it > was stopped. > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: > Closing > socket. > DEBUG | wrapperp | 2007/12/21 11:00:44 | socket read no code > (closed?). > DEBUG | wrapperp | 2007/12/21 11:00:44 | server listening on port > 32001. > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: > ShutdownHook complete > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: Server > daemon shut down > INFO | jvm 1 | 2007/12/21 11:01:07 | Shutdown hook complete. > Should > exit now. > DEBUG | wrapper | 2007/12/21 11:01:07 | JVM exited normally. > DEBUG | wrapper | 2007/12/21 11:01:07 | Signal trapped. Details: > DEBUG | wrapper | 2007/12/21 11:01:07 | signal number=17 > (SIGCHLD), > source="unknown" > DEBUG | wrapper | 2007/12/21 11:01:07 | Received SIGCHLD, > checking JVM > process status. > DEBUG | wrapper | 2007/12/21 11:01:07 | JVM process exited with > a code > of 0, leaving the wrapper exit code set to 0. > STATUS | wrapper | 2007/12/21 11:01:07 | <-- Wrapper Stopped > --- > > In both of the above cases, the shutdown hook thread itself has > its daemon flag set to false, the default. I tried setting it to > true > to see what happened. Normally a JVM does NOT wait for daemon > threads to complete before exiting, I thought maybe the same > might be true for shutdown hooks. But the JVM seems to ignore > the daemon flag for shutdown hooks. It waited for my shutdown > hook to complete regardless. > > The "Shutdown hook complete. Should exit now." message is also > being displayed, so we know that the shutdown hook is not having > any problems outputting to System.out . > > We should be able to get the shutdown hooks working correctly, > but if not, a simpler option to your work around would be to > make use of Integration Method 2, using the WrapperStartStopApp > helper class. You can configure that to always wait for the > stop method to complete. It does not rely on shutdown hooks. > > Also, as I appear to be having problems reproducing a problem that > you are obviously able to easily reproduce, would it be possible for > you to create a simple class running under the WrapperSimpleApp > integration method that I can add to my test suite? > > Thanks, > Leif > > Markus Schlegel wrote: > > I think i am getting mad. > > I've checked the whole code for System.exit() statements. > > I've tested 1000 times, always with the same result that our > > ShutdownHook does not finish. > > I've also added a finally-clause in the shutdown hook, but even that > > will not be executed (so there is no exception, the VM just exits). > > I've also experimented with increasing the shutdown- and > > jvm-exit-timeouts, but with no success. > > > > I've now changed our maintenance code. We no longer use a > ShutdownHook > > to cleanup and shutdown the services, since this seems not to work > > reliable. Instead we register as a WrapperEventListener on > startup and > > trap all Control and ServiceControl Events that must lead in a > > shutdown and perform our cleanup there in. > > Because WrapperManager.restart() and WrapperManager.stop() do > not fire > > such events, I have to handle these cases additionally > > (shutdown/restart performed from within our AdministrationClient). > > > > In our trunk, I would like to implement WrapperListener instead of > > WrapperEventListener, but then I require some new License for our > > 3.3-alpha release. > > > > Do you think this is a reasonable workaround? > > > > Markus > > > > 2007/12/19, Leif Mortenson <le...@ta... > <mailto:le...@ta...> > > <mailto:le...@ta... <mailto:le...@ta...>> >: > > > > Markus, > > Looking at your log, the Wrapper is not doing anything > special like > > killing the jvm process. In that case, the JVM is handling the > > shutdown of the JVM. The Wrapper simply calls System.exit > in this > > case and runs its own shutdown hook to clean up after itself. > > > > The JVM should be waiting for all normal shutdown hooks to > > complete before the JVM exits. Are you certain that your JVM > > is not exiting due to an exception of some kind? try adding a > > Try finally block and see if that code is getting run. > > > > Cheers, > > Leif > > > > > > > > Markus Schlegel wrote: > > > Hi > > > We have encountered a problem with service wrapper (3.2 > and 3.3). > > > We use the WrapperSimpleApp as integration method. We have > registred > > > our own Shutdown hook. > > > When we stop the service using the service mgmt console, some > > parts of > > > the Shutdown hook runs, but the vm is being terminated > before the > > > shutdownhook is finished. > > > See the logfile using the debug-option: > > > > > > wrapper | 2007/12/19 10:49:49 | SERVICE_CONTROL_STOP > > > wrapper | 2007/12/19 10:49:49 | wrapperStopProcess(0) > called. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > Received a > > > packet SERVICE_CONTROL_CODE : 1 > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > ServiceControlCode from Wrapper with code 1 > > > wrapper | 2007/12/19 10:49:49 | Sending stop signal to JVM > > > wrapperp | 2007/12/19 10:49:49 | send a packet STOP : NULL > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > Received a > > > packet STOP : > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Thread, > > > Wrapper-Connection, handling the shutdown process. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > calling > > > listener.stop() > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > Waiting for > > > WrapperListener.stop runner thread to complete. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > WrapperListener.stop runner thread started. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperSimpleApp Debug: > stop(0) > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > WrapperListener.stop runner thread stopped. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > returned from > > > listener.stop() -> 0 > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > shutdownJVM(0) > > > Thread:Wrapper-Connection > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > Send a packet > > > STOPPED : 0 > > > wrapperp | 2007/12/19 10:49:49 | read a packet STOPPED : 0 > > > wrapper | 2007/12/19 10:49:49 | JVM signalled that it was > stopped. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Closing > > socket. > > > wrapperp | 2007/12/19 10:49:49 | socket read no code > (closed?). > > > wrapperp | 2007/12/19 10:49:49 | server listening on port > 32001. > > > jvm 1 | 2007/12/19 10:49:50 | WrapperManager Debug: calling > > > System.exit(0) > > > > > > -->this is our shutdown hook now > > > > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Shutdown hook > called > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop Server > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Wenn der > Server eine > > > grosse Anzahl Daten sichern muss, kann dies eine Weile > dauern... > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): All cabinets > closed. > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop services... > > > > > > -->this was the last message of our shutdown hook, but > there shuld > > > come more than that... > > > > > > wrapper | 2007/12/19 10:49:50 | JVM process exited with a > code > > of 0, > > > leaving the wrapper exit code set to 0. > > > wrapper | 2007/12/19 10:49:50 | JVM exited normally. > > > wrapper | 2007/12/19 10:49:50 | <-- Wrapper Stopped > > > > > > > > > > > > > > > It seems to me, that our Shutdown hook is interrupted by the > > exit of > > > the VM. Also the log is not always exactly the same, > sometimes our > > > shutdown hook has no time to start running at all. > > > Is this exit of the VM caused by the wrapper? > > > Is this a bug? > > > I think the documentation on the website for integration > method > > 1 is > > > wrong when you look at the behavior above. > > > > > > > > > > > > Thanks > > > Markus > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > ------------------------------------------------------------------------- > > > > > SF.Net email is sponsored by: > > > Check out the new SourceForge.net Marketplace. > > > It's the best place to buy or sell services > > > for just about anything Open Source. > > > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Wrapper-user mailing list > > > Wra...@li... > <mailto:Wra...@li...> > > <mailto: Wra...@li... > <mailto:Wra...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > < https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > > > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > <mailto:Wra...@li...> > > <mailto:Wra...@li... > <mailto:Wra...@li...>> > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > <https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > <mailto:Wra...@li...> > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > <https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > <mailto:Wra...@li...> > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Markus S. <sc...@gm...> - 2007-12-21 08:19:38
|
Please have a look at my first post, and look to the time of the log statements. Our setting for the timeouts in the wrapper.conf are: wrapper.shutdown.timeout=200 wrapper.jvm_exit.timeout=200 This means, that the wrapper should wait 200 seconds for the jvm to exit. Also your documentation says, that if the jvm_exit timeout is reached, a message like wrapper | Shutdown failed: Timed out waiting for the JVM to terminate. wrapper | Java Virtual Machine did not exit on request, terminated will be written to the log. There is no such message. Also I compared your log and my one. They are not only different at the beginning (You are maybe using the latest version 3.3.0-c, i am using 3.3.0-a), they are also different at the end. My log contains the statements: wrapperp | 2007/12/19 10:49:49 | socket read no code (closed?). wrapperp | 2007/12/19 10:49:49 | server listening on port 32001. jvm 1 | 2007/12/19 10:49:50 | WrapperManager Debug: calling System.exit (0) jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Shutdown hook called while your log has: DEBUG | wrapperp | 2007/12/21 11:00:44 | socket read no code (closed?). DEBUG | wrapperp | 2007/12/21 11:00:44 | server listening on port 32001. INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: ShutdownHook complete INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: Server daemon shut down INFO | jvm 1 | 2007/12/21 11:01:07 | Shutdown hook complete. Should exit now. As you can see, there is a "calling System.exit(0)" in my log. This comes from WrapperManager.shutdownJVM, line 3136. Maybe it has something to do with the kind of starting the shutdown. Maybe your should try your testcase using windows Service Mgmt Console to shutdown. What do you think about that? markus 2007/12/21, Leif Mortenson <le...@ta...>: > > Markus, > I went back today and retested how shutdown hooks work with the > Wrapper today. > > This is the end of the debug log output for a shutdown hook which > takes longer to run than the configured jvm_exit timeout. Note > that the WrapperManager's internal shutdown hook completes > promptly, but the JVM does not actually terminate because the > custom shutdown hook is still running: > --- > DEBUG | wrapperp | 2007/12/21 10:43:46 | read a packet STOP : 0 > DEBUG | wrapper | 2007/12/21 10:43:46 | JVM requested a shutdown. (0) > DEBUG | wrapper | 2007/12/21 10:43:46 | wrapperStopProcess(0) called. > DEBUG | wrapper | 2007/12/21 10:43:46 | Sending stop signal to JVM > DEBUG | wrapperp | 2007/12/21 10:43:46 | send a packet STOP : NULL > INFO | jvm 1 | 2007/12/21 10:43:46 | WrapperManager Debug: Received > a packet STOP : > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: Thread, > Wrapper-Shutdown-Hook, handling the shutdown process. > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: calling > listener.stop() > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperSimpleApp Debug: stop(0) > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: returned > from listener.stop() -> 0 > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: > shutdownJVM(0) Thread:Wrapper-Shutdown-Hook > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: Send a > packet STOPPED : 0 > DEBUG | wrapperp | 2007/12/21 10:43:47 | read a packet STOPPED : 0 > DEBUG | wrapper | 2007/12/21 10:43:47 | JVM signalled that it was > stopped. > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: Closing > socket. > DEBUG | wrapperp | 2007/12/21 10:43:48 | socket read no code (closed?). > DEBUG | wrapperp | 2007/12/21 10:43:48 | server listening on port 32001. > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: > ShutdownHook complete > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: Server > daemon shut down > ERROR | wrapper | 2007/12/21 10:44:06 | Shutdown failed: Timed out > waiting for the JVM to terminate. > ERROR | wrapper | 2007/12/21 10:44:07 | JVM did not exit on request, > terminated > DEBUG | wrapper | 2007/12/21 10:44:07 | Signal trapped. Details: > DEBUG | wrapper | 2007/12/21 10:44:07 | signal number=17 (SIGCHLD), > source="unknown" > DEBUG | wrapper | 2007/12/21 10:44:07 | Received SIGCHLD, checking JVM > process status. > STATUS | wrapper | 2007/12/21 10:44:07 | JVM received a signal SIGKILL > (9). > STATUS | wrapper | 2007/12/21 10:44:07 | <-- Wrapper Stopped > --- > > For this next run, I have extended the jvm_exit timeout long > enough to allow the custom shutdown hook to complete. It looks > pretty much the same as the last example except that shutdown > completes. > --- > DEBUG | wrapperp | 2007/12/21 11:00:42 | read a packet STOP : 0 > DEBUG | wrapper | 2007/12/21 11:00:42 | JVM requested a shutdown. (0) > DEBUG | wrapper | 2007/12/21 11:00:42 | wrapperStopProcess(0) called. > DEBUG | wrapper | 2007/12/21 11:00:42 | Sending stop signal to JVM > DEBUG | wrapperp | 2007/12/21 11:00:42 | send a packet STOP : NULL > INFO | jvm 1 | 2007/12/21 11:00:42 | WrapperManager Debug: Received > a packet STOP : > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: Thread, > Wrapper-Shutdown-Hook, handling the shutdown process. > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: calling > listener.stop() > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperSimpleApp Debug: stop(0) > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: returned > from listener.stop() -> 0 > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: > shutdownJVM(0) Thread:Wrapper-Shutdown-Hook > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: Send a > packet STOPPED : 0 > DEBUG | wrapperp | 2007/12/21 11:00:43 | read a packet STOPPED : 0 > DEBUG | wrapper | 2007/12/21 11:00:43 | JVM signalled that it was > stopped. > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: Closing > socket. > DEBUG | wrapperp | 2007/12/21 11:00:44 | socket read no code (closed?). > DEBUG | wrapperp | 2007/12/21 11:00:44 | server listening on port 32001. > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: > ShutdownHook complete > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: Server > daemon shut down > INFO | jvm 1 | 2007/12/21 11:01:07 | Shutdown hook complete. Should > exit now. > DEBUG | wrapper | 2007/12/21 11:01:07 | JVM exited normally. > DEBUG | wrapper | 2007/12/21 11:01:07 | Signal trapped. Details: > DEBUG | wrapper | 2007/12/21 11:01:07 | signal number=17 (SIGCHLD), > source="unknown" > DEBUG | wrapper | 2007/12/21 11:01:07 | Received SIGCHLD, checking JVM > process status. > DEBUG | wrapper | 2007/12/21 11:01:07 | JVM process exited with a code > of 0, leaving the wrapper exit code set to 0. > STATUS | wrapper | 2007/12/21 11:01:07 | <-- Wrapper Stopped > --- > > In both of the above cases, the shutdown hook thread itself has > its daemon flag set to false, the default. I tried setting it to true > to see what happened. Normally a JVM does NOT wait for daemon > threads to complete before exiting, I thought maybe the same > might be true for shutdown hooks. But the JVM seems to ignore > the daemon flag for shutdown hooks. It waited for my shutdown > hook to complete regardless. > > The "Shutdown hook complete. Should exit now." message is also > being displayed, so we know that the shutdown hook is not having > any problems outputting to System.out. > > We should be able to get the shutdown hooks working correctly, > but if not, a simpler option to your work around would be to > make use of Integration Method 2, using the WrapperStartStopApp > helper class. You can configure that to always wait for the > stop method to complete. It does not rely on shutdown hooks. > > Also, as I appear to be having problems reproducing a problem that > you are obviously able to easily reproduce, would it be possible for > you to create a simple class running under the WrapperSimpleApp > integration method that I can add to my test suite? > > Thanks, > Leif > > Markus Schlegel wrote: > > I think i am getting mad. > > I've checked the whole code for System.exit() statements. > > I've tested 1000 times, always with the same result that our > > ShutdownHook does not finish. > > I've also added a finally-clause in the shutdown hook, but even that > > will not be executed (so there is no exception, the VM just exits). > > I've also experimented with increasing the shutdown- and > > jvm-exit-timeouts, but with no success. > > > > I've now changed our maintenance code. We no longer use a ShutdownHook > > to cleanup and shutdown the services, since this seems not to work > > reliable. Instead we register as a WrapperEventListener on startup and > > trap all Control and ServiceControl Events that must lead in a > > shutdown and perform our cleanup there in. > > Because WrapperManager.restart() and WrapperManager.stop() do not fire > > such events, I have to handle these cases additionally > > (shutdown/restart performed from within our AdministrationClient). > > > > In our trunk, I would like to implement WrapperListener instead of > > WrapperEventListener, but then I require some new License for our > > 3.3-alpha release. > > > > Do you think this is a reasonable workaround? > > > > Markus > > > > 2007/12/19, Leif Mortenson <le...@ta... > > <mailto:le...@ta...> >: > > > > Markus, > > Looking at your log, the Wrapper is not doing anything special like > > killing the jvm process. In that case, the JVM is handling the > > shutdown of the JVM. The Wrapper simply calls System.exit in this > > case and runs its own shutdown hook to clean up after itself. > > > > The JVM should be waiting for all normal shutdown hooks to > > complete before the JVM exits. Are you certain that your JVM > > is not exiting due to an exception of some kind? try adding a > > Try finally block and see if that code is getting run. > > > > Cheers, > > Leif > > > > > > > > Markus Schlegel wrote: > > > Hi > > > We have encountered a problem with service wrapper (3.2 and 3.3). > > > We use the WrapperSimpleApp as integration method. We have > registred > > > our own Shutdown hook. > > > When we stop the service using the service mgmt console, some > > parts of > > > the Shutdown hook runs, but the vm is being terminated before the > > > shutdownhook is finished. > > > See the logfile using the debug-option: > > > > > > wrapper | 2007/12/19 10:49:49 | SERVICE_CONTROL_STOP > > > wrapper | 2007/12/19 10:49:49 | wrapperStopProcess(0) called. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > > > packet SERVICE_CONTROL_CODE : 1 > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > ServiceControlCode from Wrapper with code 1 > > > wrapper | 2007/12/19 10:49:49 | Sending stop signal to JVM > > > wrapperp | 2007/12/19 10:49:49 | send a packet STOP : NULL > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > > > packet STOP : > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Thread, > > > Wrapper-Connection, handling the shutdown process. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: calling > > > listener.stop() > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Waiting for > > > WrapperListener.stop runner thread to complete. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > WrapperListener.stop runner thread started. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperSimpleApp Debug: stop(0) > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > WrapperListener.stop runner thread stopped. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: returned > from > > > listener.stop() -> 0 > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > shutdownJVM(0) > > > Thread:Wrapper-Connection > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Send a > packet > > > STOPPED : 0 > > > wrapperp | 2007/12/19 10:49:49 | read a packet STOPPED : 0 > > > wrapper | 2007/12/19 10:49:49 | JVM signalled that it was > stopped. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Closing > > socket. > > > wrapperp | 2007/12/19 10:49:49 | socket read no code (closed?). > > > wrapperp | 2007/12/19 10:49:49 | server listening on port 32001. > > > jvm 1 | 2007/12/19 10:49:50 | WrapperManager Debug: calling > > > System.exit(0) > > > > > > -->this is our shutdown hook now > > > > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Shutdown hook called > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop Server > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Wenn der Server eine > > > grosse Anzahl Daten sichern muss, kann dies eine Weile dauern... > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): All cabinets closed. > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop services... > > > > > > -->this was the last message of our shutdown hook, but there shuld > > > come more than that... > > > > > > wrapper | 2007/12/19 10:49:50 | JVM process exited with a code > > of 0, > > > leaving the wrapper exit code set to 0. > > > wrapper | 2007/12/19 10:49:50 | JVM exited normally. > > > wrapper | 2007/12/19 10:49:50 | <-- Wrapper Stopped > > > > > > > > > > > > > > > It seems to me, that our Shutdown hook is interrupted by the > > exit of > > > the VM. Also the log is not always exactly the same, sometimes our > > > shutdown hook has no time to start running at all. > > > Is this exit of the VM caused by the wrapper? > > > Is this a bug? > > > I think the documentation on the website for integration method > > 1 is > > > wrong when you look at the behavior above. > > > > > > > > > > > > Thanks > > > Markus > > > > > > ------------------------------------------------------------------------ > > > > > > > > > ------------------------------------------------------------------------- > > > > > SF.Net email is sponsored by: > > > Check out the new SourceForge.net Marketplace. > > > It's the best place to buy or sell services > > > for just about anything Open Source. > > > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Wrapper-user mailing list > > > Wra...@li... > > <mailto:Wra...@li...> > > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > <https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > > > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > > <mailto:Wra...@li...> > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > <https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Markus S. <sc...@gm...> - 2007-12-21 07:45:28
|
How did you do your testcase? What OS do you use? Could you send me your test-app in order that I could test if it works the same on our systems? Markus 2007/12/21, Leif Mortenson <le...@ta...>: > > Markus, > I went back today and retested how shutdown hooks work with the > Wrapper today. > > This is the end of the debug log output for a shutdown hook which > takes longer to run than the configured jvm_exit timeout. Note > that the WrapperManager's internal shutdown hook completes > promptly, but the JVM does not actually terminate because the > custom shutdown hook is still running: > --- > DEBUG | wrapperp | 2007/12/21 10:43:46 | read a packet STOP : 0 > DEBUG | wrapper | 2007/12/21 10:43:46 | JVM requested a shutdown. (0) > DEBUG | wrapper | 2007/12/21 10:43:46 | wrapperStopProcess(0) called. > DEBUG | wrapper | 2007/12/21 10:43:46 | Sending stop signal to JVM > DEBUG | wrapperp | 2007/12/21 10:43:46 | send a packet STOP : NULL > INFO | jvm 1 | 2007/12/21 10:43:46 | WrapperManager Debug: Received > a packet STOP : > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: Thread, > Wrapper-Shutdown-Hook, handling the shutdown process. > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: calling > listener.stop() > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperSimpleApp Debug: stop(0) > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: returned > from listener.stop() -> 0 > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: > shutdownJVM(0) Thread:Wrapper-Shutdown-Hook > INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: Send a > packet STOPPED : 0 > DEBUG | wrapperp | 2007/12/21 10:43:47 | read a packet STOPPED : 0 > DEBUG | wrapper | 2007/12/21 10:43:47 | JVM signalled that it was > stopped. > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: Closing > socket. > DEBUG | wrapperp | 2007/12/21 10:43:48 | socket read no code (closed?). > DEBUG | wrapperp | 2007/12/21 10:43:48 | server listening on port 32001. > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: > ShutdownHook complete > INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: Server > daemon shut down > ERROR | wrapper | 2007/12/21 10:44:06 | Shutdown failed: Timed out > waiting for the JVM to terminate. > ERROR | wrapper | 2007/12/21 10:44:07 | JVM did not exit on request, > terminated > DEBUG | wrapper | 2007/12/21 10:44:07 | Signal trapped. Details: > DEBUG | wrapper | 2007/12/21 10:44:07 | signal number=17 (SIGCHLD), > source="unknown" > DEBUG | wrapper | 2007/12/21 10:44:07 | Received SIGCHLD, checking JVM > process status. > STATUS | wrapper | 2007/12/21 10:44:07 | JVM received a signal SIGKILL > (9). > STATUS | wrapper | 2007/12/21 10:44:07 | <-- Wrapper Stopped > --- > > For this next run, I have extended the jvm_exit timeout long > enough to allow the custom shutdown hook to complete. It looks > pretty much the same as the last example except that shutdown > completes. > --- > DEBUG | wrapperp | 2007/12/21 11:00:42 | read a packet STOP : 0 > DEBUG | wrapper | 2007/12/21 11:00:42 | JVM requested a shutdown. (0) > DEBUG | wrapper | 2007/12/21 11:00:42 | wrapperStopProcess(0) called. > DEBUG | wrapper | 2007/12/21 11:00:42 | Sending stop signal to JVM > DEBUG | wrapperp | 2007/12/21 11:00:42 | send a packet STOP : NULL > INFO | jvm 1 | 2007/12/21 11:00:42 | WrapperManager Debug: Received > a packet STOP : > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: Thread, > Wrapper-Shutdown-Hook, handling the shutdown process. > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: calling > listener.stop() > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperSimpleApp Debug: stop(0) > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: returned > from listener.stop() -> 0 > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: > shutdownJVM(0) Thread:Wrapper-Shutdown-Hook > INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: Send a > packet STOPPED : 0 > DEBUG | wrapperp | 2007/12/21 11:00:43 | read a packet STOPPED : 0 > DEBUG | wrapper | 2007/12/21 11:00:43 | JVM signalled that it was > stopped. > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: Closing > socket. > DEBUG | wrapperp | 2007/12/21 11:00:44 | socket read no code (closed?). > DEBUG | wrapperp | 2007/12/21 11:00:44 | server listening on port 32001. > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: > ShutdownHook complete > INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: Server > daemon shut down > INFO | jvm 1 | 2007/12/21 11:01:07 | Shutdown hook complete. Should > exit now. > DEBUG | wrapper | 2007/12/21 11:01:07 | JVM exited normally. > DEBUG | wrapper | 2007/12/21 11:01:07 | Signal trapped. Details: > DEBUG | wrapper | 2007/12/21 11:01:07 | signal number=17 (SIGCHLD), > source="unknown" > DEBUG | wrapper | 2007/12/21 11:01:07 | Received SIGCHLD, checking JVM > process status. > DEBUG | wrapper | 2007/12/21 11:01:07 | JVM process exited with a code > of 0, leaving the wrapper exit code set to 0. > STATUS | wrapper | 2007/12/21 11:01:07 | <-- Wrapper Stopped > --- > > In both of the above cases, the shutdown hook thread itself has > its daemon flag set to false, the default. I tried setting it to true > to see what happened. Normally a JVM does NOT wait for daemon > threads to complete before exiting, I thought maybe the same > might be true for shutdown hooks. But the JVM seems to ignore > the daemon flag for shutdown hooks. It waited for my shutdown > hook to complete regardless. > > The "Shutdown hook complete. Should exit now." message is also > being displayed, so we know that the shutdown hook is not having > any problems outputting to System.out. > > We should be able to get the shutdown hooks working correctly, > but if not, a simpler option to your work around would be to > make use of Integration Method 2, using the WrapperStartStopApp > helper class. You can configure that to always wait for the > stop method to complete. It does not rely on shutdown hooks. > > Also, as I appear to be having problems reproducing a problem that > you are obviously able to easily reproduce, would it be possible for > you to create a simple class running under the WrapperSimpleApp > integration method that I can add to my test suite? > > Thanks, > Leif > > Markus Schlegel wrote: > > I think i am getting mad. > > I've checked the whole code for System.exit() statements. > > I've tested 1000 times, always with the same result that our > > ShutdownHook does not finish. > > I've also added a finally-clause in the shutdown hook, but even that > > will not be executed (so there is no exception, the VM just exits). > > I've also experimented with increasing the shutdown- and > > jvm-exit-timeouts, but with no success. > > > > I've now changed our maintenance code. We no longer use a ShutdownHook > > to cleanup and shutdown the services, since this seems not to work > > reliable. Instead we register as a WrapperEventListener on startup and > > trap all Control and ServiceControl Events that must lead in a > > shutdown and perform our cleanup there in. > > Because WrapperManager.restart() and WrapperManager.stop() do not fire > > such events, I have to handle these cases additionally > > (shutdown/restart performed from within our AdministrationClient). > > > > In our trunk, I would like to implement WrapperListener instead of > > WrapperEventListener, but then I require some new License for our > > 3.3-alpha release. > > > > Do you think this is a reasonable workaround? > > > > Markus > > > > 2007/12/19, Leif Mortenson <le...@ta... > > <mailto:le...@ta...> >: > > > > Markus, > > Looking at your log, the Wrapper is not doing anything special like > > killing the jvm process. In that case, the JVM is handling the > > shutdown of the JVM. The Wrapper simply calls System.exit in this > > case and runs its own shutdown hook to clean up after itself. > > > > The JVM should be waiting for all normal shutdown hooks to > > complete before the JVM exits. Are you certain that your JVM > > is not exiting due to an exception of some kind? try adding a > > Try finally block and see if that code is getting run. > > > > Cheers, > > Leif > > > > > > > > Markus Schlegel wrote: > > > Hi > > > We have encountered a problem with service wrapper (3.2 and 3.3). > > > We use the WrapperSimpleApp as integration method. We have > registred > > > our own Shutdown hook. > > > When we stop the service using the service mgmt console, some > > parts of > > > the Shutdown hook runs, but the vm is being terminated before the > > > shutdownhook is finished. > > > See the logfile using the debug-option: > > > > > > wrapper | 2007/12/19 10:49:49 | SERVICE_CONTROL_STOP > > > wrapper | 2007/12/19 10:49:49 | wrapperStopProcess(0) called. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > > > packet SERVICE_CONTROL_CODE : 1 > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > ServiceControlCode from Wrapper with code 1 > > > wrapper | 2007/12/19 10:49:49 | Sending stop signal to JVM > > > wrapperp | 2007/12/19 10:49:49 | send a packet STOP : NULL > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > > > packet STOP : > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Thread, > > > Wrapper-Connection, handling the shutdown process. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: calling > > > listener.stop() > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Waiting for > > > WrapperListener.stop runner thread to complete. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > WrapperListener.stop runner thread started. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperSimpleApp Debug: stop(0) > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > > WrapperListener.stop runner thread stopped. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: returned > from > > > listener.stop() -> 0 > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > shutdownJVM(0) > > > Thread:Wrapper-Connection > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Send a > packet > > > STOPPED : 0 > > > wrapperp | 2007/12/19 10:49:49 | read a packet STOPPED : 0 > > > wrapper | 2007/12/19 10:49:49 | JVM signalled that it was > stopped. > > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Closing > > socket. > > > wrapperp | 2007/12/19 10:49:49 | socket read no code (closed?). > > > wrapperp | 2007/12/19 10:49:49 | server listening on port 32001. > > > jvm 1 | 2007/12/19 10:49:50 | WrapperManager Debug: calling > > > System.exit(0) > > > > > > -->this is our shutdown hook now > > > > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Shutdown hook called > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop Server > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Wenn der Server eine > > > grosse Anzahl Daten sichern muss, kann dies eine Weile dauern... > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): All cabinets closed. > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop services... > > > > > > -->this was the last message of our shutdown hook, but there shuld > > > come more than that... > > > > > > wrapper | 2007/12/19 10:49:50 | JVM process exited with a code > > of 0, > > > leaving the wrapper exit code set to 0. > > > wrapper | 2007/12/19 10:49:50 | JVM exited normally. > > > wrapper | 2007/12/19 10:49:50 | <-- Wrapper Stopped > > > > > > > > > > > > > > > It seems to me, that our Shutdown hook is interrupted by the > > exit of > > > the VM. Also the log is not always exactly the same, sometimes our > > > shutdown hook has no time to start running at all. > > > Is this exit of the VM caused by the wrapper? > > > Is this a bug? > > > I think the documentation on the website for integration method > > 1 is > > > wrong when you look at the behavior above. > > > > > > > > > > > > Thanks > > > Markus > > > > > > ------------------------------------------------------------------------ > > > > > > > > > ------------------------------------------------------------------------- > > > > > SF.Net email is sponsored by: > > > Check out the new SourceForge.net Marketplace. > > > It's the best place to buy or sell services > > > for just about anything Open Source. > > > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Wrapper-user mailing list > > > Wra...@li... > > <mailto:Wra...@li...> > > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > <https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > > > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > > <mailto:Wra...@li...> > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > <https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Leif M. <le...@ta...> - 2007-12-21 07:42:38
|
Barry, As a follow up. This sparked an idea. So the next release 3.3.0 will now allow you to execute a command like the following to send a control code to a running service. bin\wrapper.exe -l=128 ..\conf\wrapper.conf bin\wrapper.exe --controlcode=128 ..\conf\wrapper.conf Cheers, Leif Leif Mortenson wrote: > Barry, > It depends on exactly what it is that you want to trigger. > Is it a life cycle action of the Wrapper to to start a piece of > arbitrary code in your server. > > I assume the later. > > 1) The Wrapper allows you to capture and react to user defined > service control codes by registering a WrapperEventListener > using the following method call: > WrapperManager.addWrapperEventListener(l,WrapperEventListener.EVENT_FLAG_SERVICE); > Your listener will then receive WrapperServiceControlEvents > whenever your service receives any control code, including user > codes. > The drawback here is with the ability to easily send those > custom codes. Do you know of a way to do it from the command > prompt? > > 2) The way I have done it in the past is to use the WrapperActionServer > class. This creates a very simple telnet server which receives one > character commands and then immediately closes the connections. > It comes with a number of predefined commands, but you can also > register your own using the registerAction method which takes the > trigger character and a Runnable instance. > A sample code fragment can be found in the javadocs for > WrapperActionServer. > > This solution works nicely as you can control it from anywhere > by simply using a telnet client. The drawback is that it is not very > secure as currently implemented. That could be resolved by adding > Passwords, IP masks etc, but it is not in there at the moment. > > See the javadocs for documentation on all of the above: > http://wrapper.tanukisoftware.org/doc/english/javadocs.html > > Cheers, > Leif > > Barry Andrews wrote: > >> Hi All, >> >> I am in the process of evaluating Java Service Wrapper for Windows and I >> am wondering if there is a built in way to communicate to a wrapped >> service? >> >> I have some code that I need to run as a Windows service and I need to >> be able to communicate to it from another process and tell it to run. On >> Windows you have you have the ServiceBase.OnCustomCommand listener. >> >> I have thought about different ways to communicate this event to the >> service. One way is programmatically pausing the service, ( "net pause >> <service name>" ) and continuing it when I need it to run. The problem >> with this is it needs to work for someone logged in as a regular "User", >> not just an admin. The service would have admin privileges, but the >> program may only have User privileges. >> >> I also thought about communicating via ports, but I didn't know if there >> was some communication functionality already built in that I was just >> overlooking? Any thoughts on this? >> >> Many thanks to you all. >> >> -B >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services >> for just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> _______________________________________________ >> Wrapper-user mailing list >> Wra...@li... >> https://lists.sourceforge.net/lists/listinfo/wrapper-user >> >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Leif M. <le...@ta...> - 2007-12-21 05:35:28
|
Barry,
It depends on exactly what it is that you want to trigger.
Is it a life cycle action of the Wrapper to to start a piece of
arbitrary code in your server.
I assume the later.
1) The Wrapper allows you to capture and react to user defined
service control codes by registering a WrapperEventListener
using the following method call:
WrapperManager.addWrapperEventListener(l,WrapperEventListener.EVENT_FLAG_SERVICE);
Your listener will then receive WrapperServiceControlEvents
whenever your service receives any control code, including user
codes.
The drawback here is with the ability to easily send those
custom codes. Do you know of a way to do it from the command
prompt?
2) The way I have done it in the past is to use the WrapperActionServer
class. This creates a very simple telnet server which receives one
character commands and then immediately closes the connections.
It comes with a number of predefined commands, but you can also
register your own using the registerAction method which takes the
trigger character and a Runnable instance.
A sample code fragment can be found in the javadocs for
WrapperActionServer.
This solution works nicely as you can control it from anywhere
by simply using a telnet client. The drawback is that it is not very
secure as currently implemented. That could be resolved by adding
Passwords, IP masks etc, but it is not in there at the moment.
See the javadocs for documentation on all of the above:
http://wrapper.tanukisoftware.org/doc/english/javadocs.html
Cheers,
Leif
Barry Andrews wrote:
> Hi All,
>
> I am in the process of evaluating Java Service Wrapper for Windows and I
> am wondering if there is a built in way to communicate to a wrapped
> service?
>
> I have some code that I need to run as a Windows service and I need to
> be able to communicate to it from another process and tell it to run. On
> Windows you have you have the ServiceBase.OnCustomCommand listener.
>
> I have thought about different ways to communicate this event to the
> service. One way is programmatically pausing the service, ( "net pause
> <service name>" ) and continuing it when I need it to run. The problem
> with this is it needs to work for someone logged in as a regular "User",
> not just an admin. The service would have admin privileges, but the
> program may only have User privileges.
>
> I also thought about communicating via ports, but I didn't know if there
> was some communication functionality already built in that I was just
> overlooking? Any thoughts on this?
>
> Many thanks to you all.
>
> -B
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
|
|
From: Leif M. <le...@ta...> - 2007-12-21 05:15:26
|
David, Can you set wrapper.debug=true in your configuration file and then post the resulting wrapper.log file? That should include notification if any of the jar files on the class path can not be loaded. Could you also most the manifest file of your tileserver.jar file? Thanks, Leif davidbeers wrote: > Thanks for the quick reply, Leif! I think I'm going to like using this > software. :) > > There's no classpath specified in the manifest, but I'm glad to know about > this for the future. The class file that isn't being found is the main > class: "WrapperSimpleApp: Unable to locate the class > com.pikesoft.TileServer: java.lang.ClassNotFoundException: > com.pikesoft.TileServer" > > -David > > > Leif Mortenson-2 wrote: > >> Does your jar's manifest file specify a classpath like the following? >> Class-Path: log4j.jar >> >> If so, it is necessary to include all of those files in the classpath as >> well. >> >> The next question is what is the file class that is not being found? >> >> Cheers, >> Leif >> >> davidbeers wrote: >> >>> I have an executable jar with a main class whose name I've verified from >>> the >>> manifest (I built the jar myself). Wrapper seems unable to execute it, >>> issuing a ClassNotFoundException. I've looked my wrapper classpath over >>> and >>> can't see what the problem could be. The salient bits of my wrapper.conf >>> look like this: >>> >>> wrapper.java.classpath.1=../lib/wrapper.jar >>> wrapper.java.classpath.2=../lib/tileserver.jar >>> >>> wrapper.java.library.path.1=../lib >>> >>> wrapper.app.parameter.1=com.pikesoft.TileServer >>> >>> tileserver.jar is my executable jar, it's located in the lib directory as >>> described, and com.pikesoft.TileServer is the fully qualified name of its >>> main class. From the FAQ it seems like this is all as it should be, but >>> I'm >>> obviously missing something! >>> > > |
|
From: Leif M. <le...@ta...> - 2007-12-21 02:11:49
|
Markus, I went back today and retested how shutdown hooks work with the Wrapper today. This is the end of the debug log output for a shutdown hook which takes longer to run than the configured jvm_exit timeout. Note that the WrapperManager's internal shutdown hook completes promptly, but the JVM does not actually terminate because the custom shutdown hook is still running: --- DEBUG | wrapperp | 2007/12/21 10:43:46 | read a packet STOP : 0 DEBUG | wrapper | 2007/12/21 10:43:46 | JVM requested a shutdown. (0) DEBUG | wrapper | 2007/12/21 10:43:46 | wrapperStopProcess(0) called. DEBUG | wrapper | 2007/12/21 10:43:46 | Sending stop signal to JVM DEBUG | wrapperp | 2007/12/21 10:43:46 | send a packet STOP : NULL INFO | jvm 1 | 2007/12/21 10:43:46 | WrapperManager Debug: Received a packet STOP : INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: Thread, Wrapper-Shutdown-Hook, handling the shutdown process. INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: calling listener.stop() INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperSimpleApp Debug: stop(0) INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: returned from listener.stop() -> 0 INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: shutdownJVM(0) Thread:Wrapper-Shutdown-Hook INFO | jvm 1 | 2007/12/21 10:43:47 | WrapperManager Debug: Send a packet STOPPED : 0 DEBUG | wrapperp | 2007/12/21 10:43:47 | read a packet STOPPED : 0 DEBUG | wrapper | 2007/12/21 10:43:47 | JVM signalled that it was stopped. INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: Closing socket. DEBUG | wrapperp | 2007/12/21 10:43:48 | socket read no code (closed?). DEBUG | wrapperp | 2007/12/21 10:43:48 | server listening on port 32001. INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: ShutdownHook complete INFO | jvm 1 | 2007/12/21 10:43:48 | WrapperManager Debug: Server daemon shut down ERROR | wrapper | 2007/12/21 10:44:06 | Shutdown failed: Timed out waiting for the JVM to terminate. ERROR | wrapper | 2007/12/21 10:44:07 | JVM did not exit on request, terminated DEBUG | wrapper | 2007/12/21 10:44:07 | Signal trapped. Details: DEBUG | wrapper | 2007/12/21 10:44:07 | signal number=17 (SIGCHLD), source="unknown" DEBUG | wrapper | 2007/12/21 10:44:07 | Received SIGCHLD, checking JVM process status. STATUS | wrapper | 2007/12/21 10:44:07 | JVM received a signal SIGKILL (9). STATUS | wrapper | 2007/12/21 10:44:07 | <-- Wrapper Stopped --- For this next run, I have extended the jvm_exit timeout long enough to allow the custom shutdown hook to complete. It looks pretty much the same as the last example except that shutdown completes. --- DEBUG | wrapperp | 2007/12/21 11:00:42 | read a packet STOP : 0 DEBUG | wrapper | 2007/12/21 11:00:42 | JVM requested a shutdown. (0) DEBUG | wrapper | 2007/12/21 11:00:42 | wrapperStopProcess(0) called. DEBUG | wrapper | 2007/12/21 11:00:42 | Sending stop signal to JVM DEBUG | wrapperp | 2007/12/21 11:00:42 | send a packet STOP : NULL INFO | jvm 1 | 2007/12/21 11:00:42 | WrapperManager Debug: Received a packet STOP : INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: Thread, Wrapper-Shutdown-Hook, handling the shutdown process. INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: calling listener.stop() INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperSimpleApp Debug: stop(0) INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: returned from listener.stop() -> 0 INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: shutdownJVM(0) Thread:Wrapper-Shutdown-Hook INFO | jvm 1 | 2007/12/21 11:00:43 | WrapperManager Debug: Send a packet STOPPED : 0 DEBUG | wrapperp | 2007/12/21 11:00:43 | read a packet STOPPED : 0 DEBUG | wrapper | 2007/12/21 11:00:43 | JVM signalled that it was stopped. INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: Closing socket. DEBUG | wrapperp | 2007/12/21 11:00:44 | socket read no code (closed?). DEBUG | wrapperp | 2007/12/21 11:00:44 | server listening on port 32001. INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: ShutdownHook complete INFO | jvm 1 | 2007/12/21 11:00:44 | WrapperManager Debug: Server daemon shut down INFO | jvm 1 | 2007/12/21 11:01:07 | Shutdown hook complete. Should exit now. DEBUG | wrapper | 2007/12/21 11:01:07 | JVM exited normally. DEBUG | wrapper | 2007/12/21 11:01:07 | Signal trapped. Details: DEBUG | wrapper | 2007/12/21 11:01:07 | signal number=17 (SIGCHLD), source="unknown" DEBUG | wrapper | 2007/12/21 11:01:07 | Received SIGCHLD, checking JVM process status. DEBUG | wrapper | 2007/12/21 11:01:07 | JVM process exited with a code of 0, leaving the wrapper exit code set to 0. STATUS | wrapper | 2007/12/21 11:01:07 | <-- Wrapper Stopped --- In both of the above cases, the shutdown hook thread itself has its daemon flag set to false, the default. I tried setting it to true to see what happened. Normally a JVM does NOT wait for daemon threads to complete before exiting, I thought maybe the same might be true for shutdown hooks. But the JVM seems to ignore the daemon flag for shutdown hooks. It waited for my shutdown hook to complete regardless. The "Shutdown hook complete. Should exit now." message is also being displayed, so we know that the shutdown hook is not having any problems outputting to System.out. We should be able to get the shutdown hooks working correctly, but if not, a simpler option to your work around would be to make use of Integration Method 2, using the WrapperStartStopApp helper class. You can configure that to always wait for the stop method to complete. It does not rely on shutdown hooks. Also, as I appear to be having problems reproducing a problem that you are obviously able to easily reproduce, would it be possible for you to create a simple class running under the WrapperSimpleApp integration method that I can add to my test suite? Thanks, Leif Markus Schlegel wrote: > I think i am getting mad. > I've checked the whole code for System.exit() statements. > I've tested 1000 times, always with the same result that our > ShutdownHook does not finish. > I've also added a finally-clause in the shutdown hook, but even that > will not be executed (so there is no exception, the VM just exits). > I've also experimented with increasing the shutdown- and > jvm-exit-timeouts, but with no success. > > I've now changed our maintenance code. We no longer use a ShutdownHook > to cleanup and shutdown the services, since this seems not to work > reliable. Instead we register as a WrapperEventListener on startup and > trap all Control and ServiceControl Events that must lead in a > shutdown and perform our cleanup there in. > Because WrapperManager.restart() and WrapperManager.stop() do not fire > such events, I have to handle these cases additionally > (shutdown/restart performed from within our AdministrationClient). > > In our trunk, I would like to implement WrapperListener instead of > WrapperEventListener, but then I require some new License for our > 3.3-alpha release. > > Do you think this is a reasonable workaround? > > Markus > > 2007/12/19, Leif Mortenson <le...@ta... > <mailto:le...@ta...> >: > > Markus, > Looking at your log, the Wrapper is not doing anything special like > killing the jvm process. In that case, the JVM is handling the > shutdown of the JVM. The Wrapper simply calls System.exit in this > case and runs its own shutdown hook to clean up after itself. > > The JVM should be waiting for all normal shutdown hooks to > complete before the JVM exits. Are you certain that your JVM > is not exiting due to an exception of some kind? try adding a > Try finally block and see if that code is getting run. > > Cheers, > Leif > > > > Markus Schlegel wrote: > > Hi > > We have encountered a problem with service wrapper (3.2 and 3.3). > > We use the WrapperSimpleApp as integration method. We have registred > > our own Shutdown hook. > > When we stop the service using the service mgmt console, some > parts of > > the Shutdown hook runs, but the vm is being terminated before the > > shutdownhook is finished. > > See the logfile using the debug-option: > > > > wrapper | 2007/12/19 10:49:49 | SERVICE_CONTROL_STOP > > wrapper | 2007/12/19 10:49:49 | wrapperStopProcess(0) called. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > > packet SERVICE_CONTROL_CODE : 1 > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > ServiceControlCode from Wrapper with code 1 > > wrapper | 2007/12/19 10:49:49 | Sending stop signal to JVM > > wrapperp | 2007/12/19 10:49:49 | send a packet STOP : NULL > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > > packet STOP : > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Thread, > > Wrapper-Connection, handling the shutdown process. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: calling > > listener.stop() > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Waiting for > > WrapperListener.stop runner thread to complete. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > WrapperListener.stop runner thread started. > > jvm 1 | 2007/12/19 10:49:49 | WrapperSimpleApp Debug: stop(0) > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > WrapperListener.stop runner thread stopped. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: returned from > > listener.stop() -> 0 > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > shutdownJVM(0) > > Thread:Wrapper-Connection > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Send a packet > > STOPPED : 0 > > wrapperp | 2007/12/19 10:49:49 | read a packet STOPPED : 0 > > wrapper | 2007/12/19 10:49:49 | JVM signalled that it was stopped. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Closing > socket. > > wrapperp | 2007/12/19 10:49:49 | socket read no code (closed?). > > wrapperp | 2007/12/19 10:49:49 | server listening on port 32001. > > jvm 1 | 2007/12/19 10:49:50 | WrapperManager Debug: calling > > System.exit(0) > > > > -->this is our shutdown hook now > > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Shutdown hook called > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop Server > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Wenn der Server eine > > grosse Anzahl Daten sichern muss, kann dies eine Weile dauern... > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): All cabinets closed. > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop services... > > > > -->this was the last message of our shutdown hook, but there shuld > > come more than that... > > > > wrapper | 2007/12/19 10:49:50 | JVM process exited with a code > of 0, > > leaving the wrapper exit code set to 0. > > wrapper | 2007/12/19 10:49:50 | JVM exited normally. > > wrapper | 2007/12/19 10:49:50 | <-- Wrapper Stopped > > > > > > > > > > It seems to me, that our Shutdown hook is interrupted by the > exit of > > the VM. Also the log is not always exactly the same, sometimes our > > shutdown hook has no time to start running at all. > > Is this exit of the VM caused by the wrapper? > > Is this a bug? > > I think the documentation on the website for integration method > 1 is > > wrong when you look at the behavior above. > > > > > > > > Thanks > > Markus > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > <mailto:Wra...@li...> > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > <https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > <mailto:Wra...@li...> > https://lists.sourceforge.net/lists/listinfo/wrapper-user > <https://lists.sourceforge.net/lists/listinfo/wrapper-user> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ------------------------------------------------------------------------ > > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Tim W. <tim...@or...> - 2007-12-20 22:47:20
|
Hi We've been using the Tanuki Service Wrapper for many years now, and it's a really important tool for us. To that end we build it regularly on all our supported platforms - currently we build 3.2.3 on: - HP-UX PA-RISC2 - HP-UX IA64 - Solaris SPARC 64 - AIX 5L PPC64 - Linux x86 - Linux x86_64 - Windows x86 - Windows x64 (yes I know there are issues, but it works fine for us) We'd like to contribute binaries for wider use, as the platform support for binary releases is somewhat patchy historically, and we'd be able to produce these binaries with a good degree of regularity. How would I go about doing this? cheers tim |
|
From: Barry A. <tit...@gm...> - 2007-12-20 00:57:25
|
Hi All, I am in the process of evaluating Java Service Wrapper for Windows and I am wondering if there is a built in way to communicate to a wrapped service? I have some code that I need to run as a Windows service and I need to be able to communicate to it from another process and tell it to run. On Windows you have you have the ServiceBase.OnCustomCommand listener. I have thought about different ways to communicate this event to the service. One way is programmatically pausing the service, ( "net pause <service name>" ) and continuing it when I need it to run. The problem with this is it needs to work for someone logged in as a regular "User", not just an admin. The service would have admin privileges, but the program may only have User privileges. I also thought about communicating via ports, but I didn't know if there was some communication functionality already built in that I was just overlooking? Any thoughts on this? Many thanks to you all. -B |
|
From: Marcus L. <ml...@un...> - 2007-12-19 19:07:29
|
Just a wild guess since it matches the problem: From where do you run the wrapper executable? Is the folder ../lib really accessible from that location? As I said, just wild guessing. Cheers, Marcus. On 20/12/2007, at 0:43 , davidbeers wrote: > > Perhaps I should also mention that I'm running x86 32-bit Linux > (RHEL 4). > I've done some floundering around with the configuration getting it > to this > point and thought I saw a message somewhere about how some environment > variables are set the first time you run Wrapper. Is it possible > that some > bad config info from previous attempts to start Wrapper needs to be > unset? > If so, what do I do to clear that out? > > -David > > > davidbeers wrote: >> >> Thanks for the quick reply, Leif! I think I'm going to like using >> this >> software. :) >> >> There's no classpath specified in the manifest, but I'm glad to >> know about >> this for the future. The class file that isn't being found is the >> main >> class: "WrapperSimpleApp: Unable to locate the class >> com.pikesoft.TileServer: java.lang.ClassNotFoundException: >> com.pikesoft.TileServer" >> >> -David >> >> >> Leif Mortenson-2 wrote: >>> >>> >>> Does your jar's manifest file specify a classpath like the >>> following? >>> Class-Path: log4j.jar >>> >>> If so, it is necessary to include all of those files in the >>> classpath as >>> well. >>> >>> The next question is what is the file class that is not being found? >>> >>> Cheers, >>> Leif >>> >>> davidbeers wrote: >>>> I have an executable jar with a main class whose name I've >>>> verified from >>>> the >>>> manifest (I built the jar myself). Wrapper seems unable to >>>> execute it, >>>> issuing a ClassNotFoundException. I've looked my wrapper >>>> classpath over >>>> and >>>> can't see what the problem could be. The salient bits of my >>>> wrapper.conf >>>> look like this: >>>> >>>> wrapper.java.classpath.1=../lib/wrapper.jar >>>> wrapper.java.classpath.2=../lib/tileserver.jar >>>> >>>> wrapper.java.library.path.1=../lib >>>> >>>> wrapper.app.parameter.1=com.pikesoft.TileServer >>>> >>>> tileserver.jar is my executable jar, it's located in the lib >>>> directory >>>> as >>>> described, and com.pikesoft.TileServer is the fully qualified >>>> name of >>>> its >>>> main class. From the FAQ it seems like this is all as it should >>>> be, but >>>> I'm >>>> obviously missing something! >>> >> >> > > -- > View this message in context: http://www.nabble.com/Executable-jar-ClassNotFoundException-tp14409676p14417185.html > Sent from the Java Service Wrapper mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Markus S. <sc...@gm...> - 2007-12-19 14:16:04
|
I think i am getting mad. I've checked the whole code for System.exit() statements. I've tested 1000 times, always with the same result that our ShutdownHook does not finish. I've also added a finally-clause in the shutdown hook, but even that will not be executed (so there is no exception, the VM just exits). I've also experimented with increasing the shutdown- and jvm-exit-timeouts, but with no success. I've now changed our maintenance code. We no longer use a ShutdownHook to cleanup and shutdown the services, since this seems not to work reliable. Instead we register as a WrapperEventListener on startup and trap all Control and ServiceControl Events that must lead in a shutdown and perform our cleanup there in. Because WrapperManager.restart() and WrapperManager.stop() do not fire such events, I have to handle these cases additionally (shutdown/restart performed from within our AdministrationClient). In our trunk, I would like to implement WrapperListener instead of WrapperEventListener, but then I require some new License for our 3.3-alpharelease. Do you think this is a reasonable workaround? Markus 2007/12/19, Leif Mortenson <le...@ta...>: > > Markus, > Looking at your log, the Wrapper is not doing anything special like > killing the jvm process. In that case, the JVM is handling the > shutdown of the JVM. The Wrapper simply calls System.exit in this > case and runs its own shutdown hook to clean up after itself. > > The JVM should be waiting for all normal shutdown hooks to > complete before the JVM exits. Are you certain that your JVM > is not exiting due to an exception of some kind? try adding a > Try finally block and see if that code is getting run. > > Cheers, > Leif > > > > Markus Schlegel wrote: > > Hi > > We have encountered a problem with service wrapper (3.2 and 3.3). > > We use the WrapperSimpleApp as integration method. We have registred > > our own Shutdown hook. > > When we stop the service using the service mgmt console, some parts of > > the Shutdown hook runs, but the vm is being terminated before the > > shutdownhook is finished. > > See the logfile using the debug-option: > > > > wrapper | 2007/12/19 10:49:49 | SERVICE_CONTROL_STOP > > wrapper | 2007/12/19 10:49:49 | wrapperStopProcess(0) called. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > > packet SERVICE_CONTROL_CODE : 1 > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > ServiceControlCode from Wrapper with code 1 > > wrapper | 2007/12/19 10:49:49 | Sending stop signal to JVM > > wrapperp | 2007/12/19 10:49:49 | send a packet STOP : NULL > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > > packet STOP : > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Thread, > > Wrapper-Connection, handling the shutdown process. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: calling > > listener.stop() > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Waiting for > > WrapperListener.stop runner thread to complete. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > WrapperListener.stop runner thread started. > > jvm 1 | 2007/12/19 10:49:49 | WrapperSimpleApp Debug: stop(0) > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > > WrapperListener.stop runner thread stopped. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: returned from > > listener.stop() -> 0 > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: shutdownJVM(0) > > Thread:Wrapper-Connection > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Send a packet > > STOPPED : 0 > > wrapperp | 2007/12/19 10:49:49 | read a packet STOPPED : 0 > > wrapper | 2007/12/19 10:49:49 | JVM signalled that it was stopped. > > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Closing socket. > > wrapperp | 2007/12/19 10:49:49 | socket read no code (closed?). > > wrapperp | 2007/12/19 10:49:49 | server listening on port 32001. > > jvm 1 | 2007/12/19 10:49:50 | WrapperManager Debug: calling > > System.exit(0) > > > > -->this is our shutdown hook now > > > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Shutdown hook called > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop Server > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Wenn der Server eine > > grosse Anzahl Daten sichern muss, kann dies eine Weile dauern... > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): All cabinets closed. > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop services... > > > > -->this was the last message of our shutdown hook, but there shuld > > come more than that... > > > > wrapper | 2007/12/19 10:49:50 | JVM process exited with a code of 0, > > leaving the wrapper exit code set to 0. > > wrapper | 2007/12/19 10:49:50 | JVM exited normally. > > wrapper | 2007/12/19 10:49:50 | <-- Wrapper Stopped > > > > > > > > > > It seems to me, that our Shutdown hook is interrupted by the exit of > > the VM. Also the log is not always exactly the same, sometimes our > > shutdown hook has no time to start running at all. > > Is this exit of the VM caused by the wrapper? > > Is this a bug? > > I think the documentation on the website for integration method 1 is > > wrong when you look at the behavior above. > > > > > > > > Thanks > > Markus > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services > > for just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Wrapper-user mailing list > > Wra...@li... > > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: davidbeers <db...@gm...> - 2007-12-19 13:43:06
|
Perhaps I should also mention that I'm running x86 32-bit Linux (RHEL 4). I've done some floundering around with the configuration getting it to this point and thought I saw a message somewhere about how some environment variables are set the first time you run Wrapper. Is it possible that some bad config info from previous attempts to start Wrapper needs to be unset? If so, what do I do to clear that out? -David davidbeers wrote: > > Thanks for the quick reply, Leif! I think I'm going to like using this > software. :) > > There's no classpath specified in the manifest, but I'm glad to know about > this for the future. The class file that isn't being found is the main > class: "WrapperSimpleApp: Unable to locate the class > com.pikesoft.TileServer: java.lang.ClassNotFoundException: > com.pikesoft.TileServer" > > -David > > > Leif Mortenson-2 wrote: >> >> >> Does your jar's manifest file specify a classpath like the following? >> Class-Path: log4j.jar >> >> If so, it is necessary to include all of those files in the classpath as >> well. >> >> The next question is what is the file class that is not being found? >> >> Cheers, >> Leif >> >> davidbeers wrote: >>> I have an executable jar with a main class whose name I've verified from >>> the >>> manifest (I built the jar myself). Wrapper seems unable to execute it, >>> issuing a ClassNotFoundException. I've looked my wrapper classpath over >>> and >>> can't see what the problem could be. The salient bits of my >>> wrapper.conf >>> look like this: >>> >>> wrapper.java.classpath.1=../lib/wrapper.jar >>> wrapper.java.classpath.2=../lib/tileserver.jar >>> >>> wrapper.java.library.path.1=../lib >>> >>> wrapper.app.parameter.1=com.pikesoft.TileServer >>> >>> tileserver.jar is my executable jar, it's located in the lib directory >>> as >>> described, and com.pikesoft.TileServer is the fully qualified name of >>> its >>> main class. From the FAQ it seems like this is all as it should be, but >>> I'm >>> obviously missing something! >> > > -- View this message in context: http://www.nabble.com/Executable-jar-ClassNotFoundException-tp14409676p14417185.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
|
From: davidbeers <db...@gm...> - 2007-12-19 13:36:37
|
Thanks for the quick reply, Leif! I think I'm going to like using this software. :) There's no classpath specified in the manifest, but I'm glad to know about this for the future. The class file that isn't being found is the main class: "WrapperSimpleApp: Unable to locate the class com.pikesoft.TileServer: java.lang.ClassNotFoundException: com.pikesoft.TileServer" -David Leif Mortenson-2 wrote: > > > Does your jar's manifest file specify a classpath like the following? > Class-Path: log4j.jar > > If so, it is necessary to include all of those files in the classpath as > well. > > The next question is what is the file class that is not being found? > > Cheers, > Leif > > davidbeers wrote: >> I have an executable jar with a main class whose name I've verified from >> the >> manifest (I built the jar myself). Wrapper seems unable to execute it, >> issuing a ClassNotFoundException. I've looked my wrapper classpath over >> and >> can't see what the problem could be. The salient bits of my wrapper.conf >> look like this: >> >> wrapper.java.classpath.1=../lib/wrapper.jar >> wrapper.java.classpath.2=../lib/tileserver.jar >> >> wrapper.java.library.path.1=../lib >> >> wrapper.app.parameter.1=com.pikesoft.TileServer >> >> tileserver.jar is my executable jar, it's located in the lib directory as >> described, and com.pikesoft.TileServer is the fully qualified name of its >> main class. From the FAQ it seems like this is all as it should be, but >> I'm >> obviously missing something! > -- View this message in context: http://www.nabble.com/Executable-jar-ClassNotFoundException-tp14409676p14416910.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
|
From: Leif M. <le...@ta...> - 2007-12-19 11:40:47
|
Ben, When you kill the JVM with the task manager, it is killed immediately. If you shutdown normally then the Wrapper and your application will have a chance to run any registered shutdown hooks. My guess is that one of those is the cause of what you are seeing. Shutdown hooks are launched by the JVM, not the Wrapper so I am not able to give you info to debug them. One idea is to run in a console, press CTRL-C and then immediately press CTRL-BREAK to cause a thread dump and see what is running. That might take a few attempts to see what you want to see. If you are using the WrapperStartStopApp integration method then another difference would be the execution of the registered stop method. Cheers, Leif Ben O'Keeffe wrote: > > Hi, > > > > I have inherited a java application that is deployed on a Windows 2003 > server as a service using Java Service Wrapper, and am having some > problems that occur when the service is stopped halfway through a > database transaction. > > > > If I stop the application by terminating the JVM directly (through > Windows Task Manager), everything works fine and the database > transaction is rolled back. If I stop the Windows service halfway > through the process, the transaction is not rolled back and partial > updates are committed to the database. > > > > Is there any way I can find out what the Wrapper is doing when > shutdown nicely, and how this differs to the more brutal termination > of the JVM? > > > > Thanks, > > Ben > |
|
From: Leif M. <le...@ta...> - 2007-12-19 11:35:21
|
David, Does your jar's manifest file specify a classpath like the following? Class-Path: log4j.jar If so, it is necessary to include all of those files in the classpath as well. The next question is what is the file class that is not being found? Cheers, Leif davidbeers wrote: > I have an executable jar with a main class whose name I've verified from the > manifest (I built the jar myself). Wrapper seems unable to execute it, > issuing a ClassNotFoundException. I've looked my wrapper classpath over and > can't see what the problem could be. The salient bits of my wrapper.conf > look like this: > > wrapper.java.classpath.1=../lib/wrapper.jar > wrapper.java.classpath.2=../lib/tileserver.jar > > wrapper.java.library.path.1=../lib > > wrapper.app.parameter.1=com.pikesoft.TileServer > > tileserver.jar is my executable jar, it's located in the lib directory as > described, and com.pikesoft.TileServer is the fully qualified name of its > main class. From the FAQ it seems like this is all as it should be, but I'm > obviously missing something! Probably something stupid... <sigh/> > |
|
From: Leif M. <le...@ta...> - 2007-12-19 11:26:54
|
Markus, Looking at your log, the Wrapper is not doing anything special like killing the jvm process. In that case, the JVM is handling the shutdown of the JVM. The Wrapper simply calls System.exit in this case and runs its own shutdown hook to clean up after itself. The JVM should be waiting for all normal shutdown hooks to complete before the JVM exits. Are you certain that your JVM is not exiting due to an exception of some kind? try adding a Try finally block and see if that code is getting run. Cheers, Leif Markus Schlegel wrote: > Hi > We have encountered a problem with service wrapper (3.2 and 3.3). > We use the WrapperSimpleApp as integration method. We have registred > our own Shutdown hook. > When we stop the service using the service mgmt console, some parts of > the Shutdown hook runs, but the vm is being terminated before the > shutdownhook is finished. > See the logfile using the debug-option: > > wrapper | 2007/12/19 10:49:49 | SERVICE_CONTROL_STOP > wrapper | 2007/12/19 10:49:49 | wrapperStopProcess(0) called. > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > packet SERVICE_CONTROL_CODE : 1 > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > ServiceControlCode from Wrapper with code 1 > wrapper | 2007/12/19 10:49:49 | Sending stop signal to JVM > wrapperp | 2007/12/19 10:49:49 | send a packet STOP : NULL > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a > packet STOP : > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Thread, > Wrapper-Connection, handling the shutdown process. > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: calling > listener.stop() > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Waiting for > WrapperListener.stop runner thread to complete. > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > WrapperListener.stop runner thread started. > jvm 1 | 2007/12/19 10:49:49 | WrapperSimpleApp Debug: stop(0) > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: > WrapperListener.stop runner thread stopped. > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: returned from > listener.stop() -> 0 > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: shutdownJVM(0) > Thread:Wrapper-Connection > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Send a packet > STOPPED : 0 > wrapperp | 2007/12/19 10:49:49 | read a packet STOPPED : 0 > wrapper | 2007/12/19 10:49:49 | JVM signalled that it was stopped. > jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Closing socket. > wrapperp | 2007/12/19 10:49:49 | socket read no code (closed?). > wrapperp | 2007/12/19 10:49:49 | server listening on port 32001. > jvm 1 | 2007/12/19 10:49:50 | WrapperManager Debug: calling > System.exit(0) > > -->this is our shutdown hook now > > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Shutdown hook called > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop Server > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Wenn der Server eine > grosse Anzahl Daten sichern muss, kann dies eine Weile dauern... > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): All cabinets closed. > jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop services... > > -->this was the last message of our shutdown hook, but there shuld > come more than that... > > wrapper | 2007/12/19 10:49:50 | JVM process exited with a code of 0, > leaving the wrapper exit code set to 0. > wrapper | 2007/12/19 10:49:50 | JVM exited normally. > wrapper | 2007/12/19 10:49:50 | <-- Wrapper Stopped > > > > > It seems to me, that our Shutdown hook is interrupted by the exit of > the VM. Also the log is not always exactly the same, sometimes our > shutdown hook has no time to start running at all. > Is this exit of the VM caused by the wrapper? > Is this a bug? > I think the documentation on the website for integration method 1 is > wrong when you look at the behavior above. > > > > Thanks > Markus > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ------------------------------------------------------------------------ > > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Markus S. <sc...@gm...> - 2007-12-19 10:24:18
|
Hi We have encountered a problem with service wrapper (3.2 and 3.3). We use the WrapperSimpleApp as integration method. We have registred our own Shutdown hook. When we stop the service using the service mgmt console, some parts of the Shutdown hook runs, but the vm is being terminated before the shutdownhook is finished. See the logfile using the debug-option: wrapper | 2007/12/19 10:49:49 | SERVICE_CONTROL_STOP wrapper | 2007/12/19 10:49:49 | wrapperStopProcess(0) called. jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a packet SERVICE_CONTROL_CODE : 1 jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: ServiceControlCode from Wrapper with code 1 wrapper | 2007/12/19 10:49:49 | Sending stop signal to JVM wrapperp | 2007/12/19 10:49:49 | send a packet STOP : NULL jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Received a packet STOP : jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Thread, Wrapper-Connection, handling the shutdown process. jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: calling listener.stop () jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Waiting for WrapperListener.stop runner thread to complete. jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: WrapperListener.stoprunner thread started. jvm 1 | 2007/12/19 10:49:49 | WrapperSimpleApp Debug: stop(0) jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: WrapperListener.stoprunner thread stopped. jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: returned from listener.stop() -> 0 jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: shutdownJVM(0) Thread:Wrapper-Connection jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Send a packet STOPPED : 0 wrapperp | 2007/12/19 10:49:49 | read a packet STOPPED : 0 wrapper | 2007/12/19 10:49:49 | JVM signalled that it was stopped. jvm 1 | 2007/12/19 10:49:49 | WrapperManager Debug: Closing socket. wrapperp | 2007/12/19 10:49:49 | socket read no code (closed?). wrapperp | 2007/12/19 10:49:49 | server listening on port 32001. jvm 1 | 2007/12/19 10:49:50 | WrapperManager Debug: calling System.exit (0) -->this is our shutdown hook now jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Shutdown hook called jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop Server jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Wenn der Server eine grosse Anzahl Daten sichern muss, kann dies eine Weile dauern... jvm 1 | 2007/12/19 10:49:50 | (Log INFO): All cabinets closed. jvm 1 | 2007/12/19 10:49:50 | (Log INFO): Stop services... -->this was the last message of our shutdown hook, but there shuld come more than that... wrapper | 2007/12/19 10:49:50 | JVM process exited with a code of 0, leaving the wrapper exit code set to 0. wrapper | 2007/12/19 10:49:50 | JVM exited normally. wrapper | 2007/12/19 10:49:50 | <-- Wrapper Stopped It seems to me, that our Shutdown hook is interrupted by the exit of the VM. Also the log is not always exactly the same, sometimes our shutdown hook has no time to start running at all. Is this exit of the VM caused by the wrapper? Is this a bug? I think the documentation on the website for integration method 1 is wrong when you look at the behavior above. Thanks Markus |
|
From: <al...@gm...> - 2007-12-19 09:48:44
|
Can anyone help me debug my startup of my application? I'm stuck! kind regards /alex Output from console: "uname -a" Linux xlabsrv01 2.4.21-15.EL #1 Thu Apr 22 00:27:41 EDT 2004 i686 i686 i386 GNU/Linux [xlabsrv01 bin]: ./prs console Running xxyy... wrapper | --> Wrapper Started as Console wrapper | Using tick timer. wrapperp | server listening on port 32000. wrapper | Command[0] : /usr/bin/java wrapper | Command[1] : -Xms256m wrapper | Command[2] : -Xmx768m wrapper | Command[3] : -Djava.library.path=/home/myapp/wrapper/lib wrapper | Command[4] : -classpath wrapper | Command[5] : /home/myapp/xsmyapp.jar:/home/myapp/wrapper/lib/wrapper.jar:/home/myapp/wrapper/lib/wrappertest.jar wrapper | Command[6] : -Dwrapper.key=doq9eCRRCA7dkDGc wrapper | Command[7] : -Dwrapper.port=32000 wrapper | Command[8] : -Dwrapper.jvm.port.min=31000 wrapper | Command[9] : -Dwrapper.jvm.port.max=31999 wrapper | Command[10] : -Dwrapper.debug=TRUE wrapper | Command[11] : -Dwrapper.pid=8926 wrapper | Command[12] : -Dwrapper.version=3.2.3 wrapper | Command[13] : -Dwrapper.native_library=wrapper wrapper | Command[14] : -Dwrapper.cpu.timeout=10 wrapper | Command[15] : -Dwrapper.jvmid=1 wrapper | Command[16] : org.tanukisoftware.wrapper.test.Main wrapper | Command[17] : Prs wrapper | Command[18] : -g gls wrapper | Launching a JVM... jvm 1 | Initializing... jvm 1 | WrapperManager class initialized by thread: main Using classloader: sun.misc.Launcher$AppClassLoader@7d772e jvm 1 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1 | Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1 | jvm 1 | Wrapper Manager: JVM #1 jvm 1 | Running a 32-bit JVM. jvm 1 | Wrapper Manager: Registering shutdown hook jvm 1 | Wrapper Manager: Using wrapper jvm 1 | Load native library. One or more attempts may fail if platform specific libraries do not exist. jvm 1 | Loaded native library: libwrapper-linux-x86-32.so jvm 1 | Calling native initialization method. jvm 1 | Inside native WrapperManager initialization method jvm 1 | Java Version : 1.6.0_03-b05 Java HotSpot(TM) Client VM jvm 1 | Java VM Vendor : Sun Microsystems Inc. jvm 1 | jvm 1 | WrapperManager.start(org.tanukisoftware.wrapper.test.Main@13e205f, args["Prs", "-g gls"]) called by thread: main jvm 1 | Control event monitor thread started. jvm 1 | Startup runner thread started. jvm 1 | Communications runner thread started. jvm 1 | Open socket to wrapper...Wrapper-Connection jvm 1 | Failed attempt to bind using local port 31000 jvm 1 | Failed attempt to bind using local port 31001 jvm 1 | Opened Socket from 31002 to 32000 jvm 1 | Send a packet KEY : doq9eCRRCA7dkDGc jvm 1 | handleSocket(Socket[addr=/127.0.0.1,port=32000,localport=31002]) wrapperp | accepted a socket from 127.0.0.1 on port 31002 wrapperp | read a packet KEY : doq9eCRRCA7dkDGc wrapper | Got key from JVM: doq9eCRRCA7dkDGc wrapperp | send a packet LOW_LOG_LEVEL : 1 wrapperp | send a packet PING_TIMEOUT : 30 wrapperp | send a packet PROPERTIES : (Property Values) wrapper | Start Application. wrapperp | send a packet START : start jvm 1 | Received a packet LOW_LOG_LEVEL : 1 jvm 1 | Wrapper Manager: LowLogLevel from Wrapper is 1 jvm 1 | Received a packet PING_TIMEOUT : 30 jvm 1 | PingTimeout from Wrapper is 30000 jvm 1 | Received a packet PROPERTIES : (Property Values) jvm 1 | Received a packet START : start jvm 1 | calling WrapperListener.start() jvm 1 | Waiting for WrapperListener.start runner thread to complete. jvm 1 | WrapperListener.start runner thread started. jvm 1 | start() wrapper | JVM exited while starting the application. wrapper | Signal trapped. Details: wrapper | signal number=17 (SIGCHLD), source="unknown" wrapper | Received SIGCHLD, checking JVM process status. wrapper | JVM process exited with a code of 1, setting the wrapper exit code to 1. jvm 1 | X connection to localhost:11.0 broken (explicit kill or server shutdown). wrapperp | server listening on port 32000. wrapper | JVM was only running for 1 seconds leading to a failed restart count of 1. wrapper | Waiting 5 seconds before launching another JVM. wrapper | Signal trapped. Details: wrapper | signal number=2 (SIGINT), source="the kernel" wrapper | INT trapped. Shutting down. wrapper | wrapperStopProcess(0) called. wrapper | <-- Wrapper Stopped |
|
From: davidbeers <db...@gm...> - 2007-12-19 01:53:42
|
I have an executable jar with a main class whose name I've verified from the manifest (I built the jar myself). Wrapper seems unable to execute it, issuing a ClassNotFoundException. I've looked my wrapper classpath over and can't see what the problem could be. The salient bits of my wrapper.conf look like this: wrapper.java.classpath.1=../lib/wrapper.jar wrapper.java.classpath.2=../lib/tileserver.jar wrapper.java.library.path.1=../lib wrapper.app.parameter.1=com.pikesoft.TileServer tileserver.jar is my executable jar, it's located in the lib directory as described, and com.pikesoft.TileServer is the fully qualified name of its main class. From the FAQ it seems like this is all as it should be, but I'm obviously missing something! Probably something stupid... <sigh/> -- View this message in context: http://www.nabble.com/Executable-jar-ClassNotFoundException-tp14409676p14409676.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
|
From: Marcus L. <ml...@un...> - 2007-12-14 02:07:48
|
Hey there, I have a few issues with firewall settings and havent found anything in the old forum or mail archive. I run GridGain and OpenJMS with the wrapper as windows system service. Everything works except that i can't seem to configure a working exception for the windows firewall. (Both services need LAN connection). Here is what i tried so far: - run GridGain and OpenJMS as normal Java application with java.exe configured as exception in the firewall: this works, traffic gets trough the firewall. - run GG and OJMS as windows service (via wrapper.exe) with java.exe as exception: didn't workl, firewall seemed to block the traffic. - run GG and OJMS as windows service (via wrapper.exe) with java.exe and wrapper.exe (both wrapper.exe copies) as exception in the firewall: didn't work, again firewall seems to block the traffic. I can not create a port exception in the firewall since both application allocate some ports dynamically. I could use a script to open all ports of the machines at least to the subnet where GG and OJMS have to be available but I'd like to have an application exception instead, so there are only as much ports open as needed. Any suggestions on this one? Thanks. Marcus. |
|
From: Ben O'K. <Ben.O'<Ke...@cr...> - 2007-12-11 22:21:34
|
UNOFFICIAL Hi, =20 I have inherited a java application that is deployed on a Windows 2003 server as a service using Java Service Wrapper, and am having some problems that occur when the service is stopped halfway through a database transaction. =20 If I stop the application by terminating the JVM directly (through Windows Task Manager), everything works fine and the database transaction is rolled back. If I stop the Windows service halfway through the process, the transaction is not rolled back and partial updates are committed to the database. =20 Is there any way I can find out what the Wrapper is doing when shutdown nicely, and how this differs to the more brutal termination of the JVM? =20 Thanks, Ben ***************************************************************************= ***************************************************************************= **** This message may contain confidential information and is intended only for = the individual named. If you are not the named addressee you should not dis= seminate, distribute or copy this e-mail, or use its contents . Please noti= fy the sender immediately if you have received this e-mail by mistake and d= elete this e-mail from your system.=20 This e-mail has been scanned by The CrimTrac Agency for known computer viru= ses. http://www.crimtrac.gov.au GPO Box 1573 CANBERRA CITY ACT 2601 ***************************************************************************= ***************************************************************************= ***** |
165 messages has been excluded from this view by a project administrator.
