|
From: Leif M. <le...@ta...> - 2007-11-28 23:20:09
|
Tom, Sorry I had forgotten to check in that filePart fix on Windows. Its in now. I made all the changes originally on Linux then found that when building on Windows. I'll check the 64 bit build today. Cheers, Leif Tom Saulpaugh wrote: > Leif, > > I did an update: > > D:\JavaServiceWrapperTrunk\wrapper\wrapper>svn update > U src\c\wrappereventloop.c > U src\c\wrapper.c > U src\c\property.c > U default.properties > U doc\revisions.txt > Updated to revision 1380. > > and got this error after doing these 64-bit build commands: > > D:\JavaServiceWrapperTrunk\wrapper\wrapper>build64.bat clean D:\JavaServiceWrapperTrunk\wrapper\wrapper>build64.bat > > wrapper.c > wrapper.c(312) : error C2065: 'filePart' : undeclared identifier > wrapper.c(312) : warning C4090: 'function' : different '__ptr64' qualifiers > NMAKE : U1077: '"D:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\ > cl.EXE"' : return code '0x2' > Stop. > > BUILD FAILED > D:\repositories\metalincsmodules\Wrapper\build.xml:514: exec returned: 2 > > Total time: 4 seconds > D:\repositories\metalincsmodules\Wrapper> > > I'll try and build the 32-bit version. > > Thanks, > > Tom > > > > -----Original Message----- > From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson > Sent: Wednesday, November 28, 2007 11:18 AM > To: wra...@li... > Subject: Re: [Wrapper-user] ^^C not working sometimes > > Tom, > I have gotten this problem fixed in the SVN trunk code. It was a > problem I introduced by "cleaning up" the state engine for the 3.3.0 > release. It had not been released. > > Please give it a try and let me know if you find any other problems. > > Cheers, > Leif > > Tom Saulpaugh wrote: > >> The previous version was 3.2.3. >> We are now using version 3.3.0-b >> >> Tom >> >> -----Original Message----- >> From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson >> Sent: Tuesday, November 20, 2007 7:26 PM >> To: wra...@li... >> Subject: Re: [Wrapper-user] ^^C not working sometimes >> >> Tom, >> I agree, that something is not working correctly. You said with the >> previous >> version "2.3" it was working. Do you mean "3.2.3"? What version are you >> using now? >> >> Cheers, >> Leif >> >> Tom Saulpaugh wrote: >> >> >>> Leif, >>> >>> Here is the log during the double ctl-c. >>> >>> It takes 6 seconds to shutdown the JVM starting at >>> >>> DEBUG | wrapper | main | 2007/11/20 13:58:36 | Signal trapped. Details: >>> DEBUG | wrapper | main | 2007/11/20 13:58:36 | signal number=2 (SIGINT), source="the kernel" >>> STATUS | wrapper | main | 2007/11/20 13:58:36 | INT trapped. Shutting down. >>> DEBUG | wrapper | main | 2007/11/20 13:58:36 | wrapperStopProcess(0) called. >>> DEBUG | wrapper | main | 2007/11/20 13:58:36 | Sending stop signal to JVM >>> DEBUG | wrapperp | main | 2007/11/20 13:58:36 | send a packet STOP : NULL >>> DEBUG | wrapper | main | 2007/11/20 13:58:36 | Signal trapped. Details: >>> DEBUG | wrapper | main | 2007/11/20 13:58:36 | signal number=2 (SIGINT), source="the kernel" >>> STATUS | wrapper | main | 2007/11/20 13:58:36 | INT trapped. Forcing immediate shutdown. >>> INFO | jvm 1 | main | 2007/11/20 13:58:36 | WrapperManager Debug: Received a packet STOP : >>> INFO | jvm 1 | main | 2007/11/20 13:58:36 | WrapperManager Debug: Thread, Wrapper-Connection, handling the shutdown process. >>> INFO | jvm 1 | main | 2007/11/20 13:58:36 | WrapperManager Debug: calling listener.stop() >>> INFO | jvm 1 | main | 2007/11/20 13:58:36 | WrapperManager Debug: Waiting for WrapperListener.stop runner thread to complete. >>> INFO | jvm 1 | main | 2007/11/20 13:58:36 | WrapperManager Debug: Processing control event(WRAPPER_CTRL_C_EVENT) >>> INFO | jvm 1 | main | 2007/11/20 13:58:36 | WrapperManager Debug: WrapperManager.stop(0) called by thread: Wrapper-Control-Event-Monitor >>> INFO | jvm 1 | main | 2007/11/20 13:58:36 | WrapperManager Debug: Thread, Wrapper-Control-Event-Monitor, waiting for the JVM to exit. >>> INFO | jvm 1 | main | 2007/11/20 13:58:36 | WrapperManager Debug: WrapperListener.stop runner thread started. >>> >>> >>> < OUR JVM SHUTDOWN PROCESSING HERE> >>> . >>> . >>> . >>> < OUR JVM SHUTDOWN PROCESSING HERE> >>> >>> >>> and ending at: >>> >>> INFO | jvm 1 | main | 2007/11/20 13:58:42 | WrapperManager Debug: WrapperListener.stop runner thread stopped. >>> INFO | jvm 1 | main | 2007/11/20 13:58:42 | WrapperManager Debug: returned from listener.stop() -> 0 >>> INFO | jvm 1 | main | 2007/11/20 13:58:42 | WrapperManager Debug: shutdownJVM(0) Thread:Wrapper-Connection >>> INFO | jvm 1 | main | 2007/11/20 13:58:42 | WrapperManager Debug: Send a packet STOPPED : 0 >>> INFO | jvm 1 | main | 2007/11/20 13:58:42 | WrapperManager Debug: Closing socket. >>> INFO | jvm 1 | main | 2007/11/20 13:58:42 | WrapperManager Debug: calling System.exit(0) >>> DEBUG | wrapper | main | 2007/11/20 13:58:42 | JVM exited normally. >>> DEBUG | wrapper | main | 2007/11/20 13:58:42 | Signal trapped. Details: >>> DEBUG | wrapper | main | 2007/11/20 13:58:42 | signal number=17 (SIGCHLD), source="unknown" >>> DEBUG | wrapper | main | 2007/11/20 13:58:42 | Received SIGCHLD, checking JVM process status. >>> DEBUG | wrapper | main | 2007/11/20 13:58:42 | JVM process exited with a code of 0, leaving the wrapper exit code set to 0. >>> STATUS | wrapper | main | 2007/11/20 13:58:42 | <-- Wrapper Stopped >>> >>> It seems like that even when the wrapper says it is forcing an immediate shutdown, it is waiting for the JVM to finish and during that time our code is doing its shutdown processing, which takes 6 seconds in this case. >>> >>> I'm confused regarding the notion of "immediate". What is an immediate shutdown? How is it different than kill -9 JVM_PID? >>> >>> With the previous wrapper (2.3) this never happened. Did anything change that would affect immediate shutdown? >>> >>> Thanks for your help, >>> >>> Tom >>> >>> >>> >>> -----Original Message----- >>> From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson >>> Sent: Monday, November 19, 2007 6:28 PM >>> To: wra...@li... >>> Subject: Re: [Wrapper-user] ^^C not working sometimes >>> >>> Tom, >>> There used to be a bug where the Wrapper would sometimes mistake >>> a single CTRL-C event as two and kill the JVM. But I have never seen >>> what you are seeing. >>> >>> Could you try to reproduce this with wrapper.debug=true enabled? >>> >>> How long apart are the two CTRL-C events? Are you seeing >>> messages in the log for both of them? >>> >>> Cheers, >>> Leif >>> >>> Tom Saulpaugh wrote: >>> >>> >>> >>>> Has anyone noticed that double cntrl-c doesn't always kill the JVM? >>>> >>>> I have seen this on linux and windows. >>>> >>>> Is there a fix for this? >>>> >>>> It seems to happen when the JVM is under heavy load. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Tom >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> ------------------------------------------------------------------------- >>>> 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 >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >> ------------------------------------------------------------------------- >> 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 >> >> ------------------------------------------------------------------------- >> 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 >> >> >> > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |