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: lfleal <lew...@gm...> - 2006-11-15 21:33:45
|
Great job Daniel! You're a lifesaver :)
Daniel Mace wrote:
>
> Leif,
>
> Here are some quick notes on the essential steps required to build using
> the MS Platform SDK:
>
> * (/tools/apache-ant-1.6.2/bin/build.xml) Add support for the SetEnv.cmd
> environment script which comes with the Platform SDK - <property
> name="msvc.vcvars" value="${msvc.home}\SetEnv.Cmd"/>
>
> * (/src/c/makewin64.bat) Modify to use the Platform SDK SetEnv.cmd
> syntax - call %1 /X64 /RETAIL
>
> * (/src/c/Wrapper64.dep) Remove references to "basetsd.h"
>
> * (/src/c/WrapperJNI64.dep) Remove references to "basetsd.h"
>
> * (/src/c/Wrapper64.mak) Remove or modify (I removed) the '/machine'
> linker flags
>
> * (/src/c/WrapperJNI64.mak) Remove or modify (I removed) the '/machine'
> linker flags
>
> There might be some other things I forgot, but I believe those are the
> major steps.
>
> -----Original Message-----
> From: wra...@li...
> [mailto:wra...@li...] On Behalf Of Leif
> Mortenson
> Sent: Friday, November 10, 2006 3:34 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] I've compiled the JSW 64 bit Windows
> binaries without Visual Studio
>
> Daniel,
> I placed an order for a 64-bit system last week so I can finally get
> these 64-bit versions built myself. I am hoping to get a new release
> out by the end of year.
>
> Any notes that you could give me on how you got this working would
> save me some time once I get the new system.
>
> There are a couple other users working on getting this working as
> well so everyone would appreciate what you learned.
>
> Thanks,
> Leif
>
> Daniel Mace wrote:
>> I needed to move my Java applications using the JSW to a Xeon based 64
>
>> bit server running Windows Server 2003 RC2 Standard x64 Edition this
>> week. Much to my dismay, there is no 64 bit Windows distribution of
>> the JSW binaries. Also, I have no access to Visual Studio, which is
>> required out of the box to use the 64 bit build scripts included with
>> the JSW source package.
>>
>> Since I really, really like using JSW, I hacked up the JSW build
>> script, batch files, and Windows 64bit makefiles. I was able to
>> succesfully build wrapper.dll and wrapper.exe on this architecture
>> (with a few warnings from cl.exe about unknown arguments) using the
>> Microsoft Windows Server 2003 R2 Platform SDK (which is available for
>> free from MS at
>> http://www.microsoft.com/downloads/details.aspx?FamilyId=0BAF2B35-C656
>> -4 969-ACE8-E4C0C0716ADB&displaylang=en).
>>
>> It seems to work just fine. The most important part of the
>> modifications was removing the unnecessary dependencies to basetsd.h
>> in the Visual Studio-generated .dep files.
>>
>> If anyone is interested in a set of instructions for reproducing a
>> compilation under these circumstances, my modified makefiles/scripts,
>> or the compiled binaries themselves, just let me know via the list and
>
>> I'll work up some sort of distribution.
>>
>> Daniel Mace
>> Senior Software Engineer, Payroll Integration benefitfocus.com
>> 843-849-7476 x6393
>>
>
>
> ------------------------------------------------------------------------
> -
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
> ****************************************************************************************
> BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is
> intended only for the individual or entity to which it is addressed and
> may contain information that is confidential and protected by law.
> Unauthorized review, use, disclosure, or dissemination of this
> communication or its contents in any way is prohibited and may be
> unlawful. If you are not the intended recipient or a person responsible
> for delivering this message to an intended recipient, please notify the
> original sender immediately by e-mail or telephone, return the original
> message to the original sender or to bfp...@be..., and
> destroy all copies or derivations of the original message. Thank you.
> (BFeComNote Rev. 08/01/2005)
> ***************************************************************************************
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
--
View this message in context: http://www.nabble.com/I%27ve-compiled-the-JSW-64-bit-Windows-binaries-without-Visual-Studio-tf2610021.html#a7346327
Sent from the Java Service Wrapper mailing list archive at Nabble.com.
|
|
From: Robey P. <ro...@da...> - 2006-11-13 21:46:12
|
On 10 Nov 2006, at 15:17, Leif Mortenson wrote: > Robey, > Unfortunately, I can't simply remove this signal handling. There > have been cases on > Solaris where the Java process was receiving TERM signals from an > unknown source > that was leading to a shutdown. The fix was to add the ignore signals > features to the > wrapper. > Under normal operation, the wrapper and its JVM are shutdown using > signals > sent to the wrapper process. But unfortunately this is not always the > only target > of signals. I think ignoring signals is fine. My patch leaves the signal handler there, but doesn't do any work inside it. I think the problem is somehow involved with doing work in the handler. My notes on the crash, in case it's helpful at all: ---------- siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000000 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.tanukisoftware.wrapper.WrapperManager.nativeGetControlEvent()I+0 j org.tanukisoftware.wrapper.WrapperManager.access$2200()I+0 Dump of assembler code for function Java_org_tanukisoftware_wrapper_WrapperManager_nativeGetControlEvent: 0x000014d0 <+0>: mov $0x1,%eax 0x000014d5 <+5>: mov %eax,0x0 <-- CRASH HERE 0x000014da <+10>: mov 0x0,%eax 0x000014df <+15>: push %ebp 0x000014e0 <+16>: mov %esp,%ebp 0x000014e2 <+18>: test %eax,%eax 0x000014e4 <+20>: je 0x14ee <+30> 0x000014e6 <+22>: xor %ecx,%ecx 0x000014e8 <+24>: mov %ecx,0x0 0x000014ee <+30>: pop %ebp 0x000014ef <+31>: xor %edx,%edx 0x000014f1 <+33>: mov %edx,0x0 0x000014f7 <+39>: ret ---------- I tried adding proper synchronization to the signal handling function (ie pthread locks) but I don't think it actually helped. I'm not sure why. But it fits in with my past experience that signals and the JVM do not mix. The crashes only happen during high load, of course. robey |
|
From: Daniel M. <dan...@be...> - 2006-11-13 19:57:30
|
Leif,
Here are some quick notes on the essential steps required to build using
the MS Platform SDK:
* (/tools/apache-ant-1.6.2/bin/build.xml) Add support for the SetEnv.cmd
environment script which comes with the Platform SDK - <property
name=3D"msvc.vcvars" value=3D"${msvc.home}\SetEnv.Cmd"/>
* (/src/c/makewin64.bat) Modify to use the Platform SDK SetEnv.cmd
syntax - call %1 /X64 /RETAIL
* (/src/c/Wrapper64.dep) Remove references to "basetsd.h"
* (/src/c/WrapperJNI64.dep) Remove references to "basetsd.h"
* (/src/c/Wrapper64.mak) Remove or modify (I removed) the '/machine'
linker flags
* (/src/c/WrapperJNI64.mak) Remove or modify (I removed) the '/machine'
linker flags
There might be some other things I forgot, but I believe those are the
major steps.
-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: Friday, November 10, 2006 3:34 PM
To: wra...@li...
Subject: Re: [Wrapper-user] I've compiled the JSW 64 bit Windows
binaries without Visual Studio
Daniel,
I placed an order for a 64-bit system last week so I can finally get
these 64-bit versions built myself. I am hoping to get a new release
out by the end of year.
Any notes that you could give me on how you got this working would
save me some time once I get the new system.
There are a couple other users working on getting this working as
well so everyone would appreciate what you learned.
Thanks,
Leif
Daniel Mace wrote:
> I needed to move my Java applications using the JSW to a Xeon based 64
> bit server running Windows Server 2003 RC2 Standard x64 Edition this=20
> week. Much to my dismay, there is no 64 bit Windows distribution of=20
> the JSW binaries. Also, I have no access to Visual Studio, which is=20
> required out of the box to use the 64 bit build scripts included with=20
> the JSW source package.
>
> Since I really, really like using JSW, I hacked up the JSW build=20
> script, batch files, and Windows 64bit makefiles. I was able to=20
> succesfully build wrapper.dll and wrapper.exe on this architecture=20
> (with a few warnings from cl.exe about unknown arguments) using the=20
> Microsoft Windows Server 2003 R2 Platform SDK (which is available for=20
> free from MS at
> =
http://www.microsoft.com/downloads/details.aspx?FamilyId=3D0BAF2B35-C656
> -4 969-ACE8-E4C0C0716ADB&displaylang=3Den).
>
> It seems to work just fine. The most important part of the=20
> modifications was removing the unnecessary dependencies to basetsd.h=20
> in the Visual Studio-generated .dep files.
>
> If anyone is interested in a set of instructions for reproducing a=20
> compilation under these circumstances, my modified makefiles/scripts,=20
> or the compiled binaries themselves, just let me know via the list and
> I'll work up some sort of distribution.
>
> Daniel Mace
> Senior Software Engineer, Payroll Integration benefitfocus.com
> 843-849-7476 x6393
> =20
------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
*************************************************************************=
***************
BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is =
intended only for the individual or entity to which it is addressed and =
may contain information that is confidential and protected by law. =
Unauthorized review, use, disclosure, or dissemination of this =
communication or its contents in any way is prohibited and may be =
unlawful. If you are not the intended recipient or a person responsible =
for delivering this message to an intended recipient, please notify the =
original sender immediately by e-mail or telephone, return the original =
message to the original sender or to bfp...@be..., and =
destroy all copies or derivations of the original message. Thank you. =
(BFeComNote Rev. 08/01/2005)
*************************************************************************=
**************
|
|
From: Mehul N. S. <meh...@gm...> - 2006-11-13 15:27:21
|
'allo,
I just started using JWS last week, but am curious as to what advantages
it offers me, that I could not get with using cygrunsrv in a Cygwin
environment, which I have on my WinXP system.
Both methods allow me to run some application as a Windows Service.
cheers,
mehul
--
Mehul N. Sanghvi
email: meh...@gm...
|
|
From: Jaume O. <ob...@es...> - 2006-11-13 08:12:36
|
Hi people. I have a problem using the java wrapper. I used to run an small java chat application server, native compiled as a daemon. Since I've experienced some problems running that way, I decided to use java wrapper. All works fine, but I have a problem in the number of processes given by linux command "pstree". The application starts 2 new threads for each new client connection, so "pstree" command should show 2 more processes, but since I use the java wrapper, it shows 3 new processes, and when client disconnects, there is a process remaining running, so with the time, the number of java processes are increasing, which is a problem. I've revised the code and made sure that only 2 threads where launched, in fact, when I run the application without using the wrapper, "pstree" shows the correct number of processes, the problem comes when I run it as a daemon using the java wrapper. I use Java wrapper 3.2.3, Debian etch in a VPS virtual server. java version "1.4.2-03" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-03) Java HotSpot(TM) Client VM (build Blackdown-1.4.2-03, mixed mode) Thanks a lot in advance, Jaume Obrador. |
|
From: Mehul N. S. <meh...@gm...> - 2006-11-12 16:43:55
|
Leif,
I was able to get it started by increasing the wrapper.startup.timeout and
wrapper.startup.delay.service to both be 300. This seems to have solved the
problem as far as I can tell. That along with a bunch of permission type problems.
cheers,
mehul
Leif Mortenson said the following on 11/10/2006 5:49 PM:
> Mehul,
> The best place to look for the cause is your wrapper.log file. In
> most cases, the
> problem is pretty obvious. I am not able to make many guesses without
> seeing your
> geronimo.conf file. (It wasn't attached).
>
> If the application is working correctly in console mode, but failing
> as a service, the
> cause is most likely an environment problem. The most common causes are
> due to
> differences in the PATH and JAVA_HOME environment variables. When running
> as a console, you will be running as the user you are logged in as.
> When running as
> a service however, you will be running as the SYSTEM user by default.
>
> If you set wrapper.debug=true in your conf file, you will get even
> more detailed info
> in your wrapper.log file.
>
> Cheers,
> Leif
>
> Mehul N. Sanghvi wrote:
>> 'allo,
>>
>> I came across JWS a couple of days ago because I was looking for
>> a way to start up Apache Geronimo as a service on Windows XP Pro. It
>> took me a couple of days to figure out the wrapper.conf that I had
>> come across on Google, and using the documentation on the JWS website,
>> have managed to get things to the point where I can start Geronimo for
>> the console.
>>
>> Trying to start it as a service though does not seem to be
>> working. It just seems to stop unexpectedly. I am not sure if it is
>> JWS, or Geronimo or WinXP. I am attaching my conf file for wrapper
>> (geronimo.conf), and can provide logs if needed.
>>
>> Here is what I do to start the service:
>>
>>
>> wrapper.exe -t ..\conf\geronimo.conf
>>
>> which does tell me that it started successfully. Then when I
>> do a query
>>
>> wrapper.exe -q ..\conf\geronimo.conf
>>
>> it shows that the service is not running. Doing a "net start"
>> to see what services are running also does not show the service as
>> running. Geronimo takes a little while to start up, so I have already
>> set the time-out delay settings that I gathered from the
>> documentation. Doesn't seem to be related to that. Anyway to get
>> information as to what is happening when the service is starting ?
>>
>>
>> cheers,
>>
>> mehul
>>
>>
>
>
--
Mehul N. Sanghvi
email: meh...@gm...
|
|
From: Dave H. <DH...@xr...> - 2006-11-11 15:43:58
|
How does JSW handle Java's Locale.getDefault() behavior? When I debug my application on Windows=20 Locale.getDefault() returns the user's regional selection from the control panel. When I run it as a service (as a server also) it always returns US_en irregardless of how the regional settings are configured. What is the expected behavior? =20 I could understand that, as a service, it would ignore the user's settings because it's not running as a user application. But how does Java know this? I'm not clear on how JSW/Java interact; how would it by-pass normal Java behavior of checking the user's regional settings. I note that I do start the service often when a user is logged in and it still ignores the regional settings. =20 I am trying to figure out if this behavior is normal and expected because of JSW or if it is caused by another part of the application system. =20 Any thoughts are greatly appreciated! =20 -dh =20 |
|
From: Leif M. <le...@ta...> - 2006-11-11 11:36:22
|
Chuck,
From the log everything looks normal. I was thinking though. Is
there any chance that
your jar files are being overwritten due to a redeployment or
something? The java
classloaders will not be able to load from the new jars even if they are
the same things.
I have seen crashes in the past due to this. These are caused by JVM
and unrelated to
the Wrapper.
I often redeploy my apps with ant and sometimes forget to stop the
existing app first.
This can lead to problems like this because the original jar files were
overwritten.
I ask because you are finding the
com.metalincs.analysis.framework.Main. That would
have already been loaded from when the application was loaded. The
inner class in the
stop method would be getting loaded for the first time when the
Main.stop method was
called.
This does not show that classes are being unloaded. But that they
are not able to be
loaded the first time they are referenced.
Hope this helps.
Cheers,
Leif
Chuck Williams wrote:
> Cool, thanks. I didn't realize that would work with wrapper. The way
> I've handled it is to generate wrapper.conf automatically from a
> wrapper.conf.template that contains a marker for where the classpath
> gets inserted. Your way is cleaner!
>
> I've tried a bunch of times but don't yet have the classloading
> failure when running debug. They happen occassionally, once today,
> but before switching on wrapper.debug.
>
> I'll post it when as as it happens.
>
> In case it is helpful, here is the one that happened earlier without
> debug. This was after running the application for a while with no
> problem from the console, then typing control-C:
>
>> STATUS | wrapper | main | 2006/11/05 15:55:06 | INT trapped.
>> Shutting down.
>> INFO | jvm 1 | main | 2006/11/05 15:55:06 | Error in
>> WrapperListener.stop callback. java.lang.NoClassDefFoundError:
>> com/metalincs/analysis/framework/Main$1
>> INFO | jvm 1 | main | 2006/11/05 15:55:06 |
>> java.lang.NoClassDefFoundError: com/metalincs/analysis/framework/Main$1
>> INFO | jvm 1 | main | 2006/11/05 15:55:06 | at
>> com.metalincs.analysis.framework.Main.stop(Main.java:493)
>> INFO | jvm 1 | main | 2006/11/05 15:55:06 | at
>> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:3134)
>> STATUS | wrapper | main | 2006/11/05 15:55:08 | <-- Wrapper Stopped
>
> Main is the class that implements WrapperListener. Main$1 is an inner
> class containing the Runnable for a thread that is launched to do some
> of the shutdown activity. Here is the method, Main.stop(), Line 493
> is what you'd expect, the first code line of the method, which creates
> an instance of the inner class. (And yes, I know that wrapper can
> accomplish the same thing using the configured shutdown timeout).
>
>> public int stop(int exitCode) {
>>
>> Thread cleanStop = new Thread(new Runnable(){
>> public void run() {
>> ComponentManager.getComponentManager().shutdown();
>> stopHttpServer(bootstrapServer);
>> bootstrapServer = null;
>> if (adminServer!=null) {
>> stopHttpServer(adminServer);
>> adminServer = null;
>> }
>> if (indexServer!=null) {
>> stopHttpServer(indexServer);
>> indexServer = null;
>> }
>> if (searchServer!=null) {
>> stopHttpServer(searchServer);
>> searchServer = null;
>> }
>> }
>> });
>> cleanStop.setDaemon(true);
>> cleanStop.start();
>>
>> try {
>> cleanStop.join(hardRestartTimeout);
>> } catch (InterruptedException e) {
>> throw new RuntimeException(e);
>> }
>> if (cleanStop.isAlive())
>> logger.warn("Hard restarting AnalysisService because soft restart timed out after " + hardRestartTimeout + " millis.");
>>
>> return exitCode;
>> }
>>
|
|
From: Chuck W. <ch...@ma...> - 2006-11-11 07:55:48
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Cool, thanks. I didn't realize that would work with wrapper. The way
I've handled it is to generate wrapper.conf automatically from a
wrapper.conf.template that contains a marker for where the classpath
gets inserted. Your way is cleaner!<br>
<br>
I've tried a bunch of times but don't yet have the classloading failure
when running debug. They happen occassionally, once today, but before
switching on wrapper.debug.<br>
<br>
I'll post it when as as it happens.<br>
<br>
In case it is helpful, here is the one that happened earlier without
debug. This was after running the application for a while with no
problem from the console, then typing control-C:<br>
<br>
<blockquote type="cite">STATUS | wrapper | main | 2006/11/05
15:55:06 | INT trapped. Shutting down.<br>
INFO | jvm 1 | main | 2006/11/05 15:55:06 | Error in
WrapperListener.stop callback. java.lang.NoClassDefFoundError:
com/metalincs/analysis/framework/Main$1<br>
INFO | jvm 1 | main | 2006/11/05 15:55:06 |
java.lang.NoClassDefFoundError: com/metalincs/analysis/framework/Main$1<br>
INFO | jvm 1 | main | 2006/11/05 15:55:06 | at
com.metalincs.analysis.framework.Main.stop(Main.java:493)<br>
INFO | jvm 1 | main | 2006/11/05 15:55:06 | at
org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:3134)<br>
STATUS | wrapper | main | 2006/11/05 15:55:08 | <-- Wrapper
Stopped<br>
</blockquote>
<br>
Main is the class that implements WrapperListener. Main$1 is an inner
class containing the Runnable for a thread that is launched to do some
of the shutdown activity. Here is the method, Main.stop(), Line 493
is what you'd expect, the first code line of the method, which creates
an instance of the inner class. (And yes, I know that wrapper can
accomplish the same thing using the configured shutdown timeout).<br>
<br>
<blockquote type="cite">
<pre> public int stop(int exitCode) {</pre>
<pre> </pre>
<pre> Thread cleanStop = new Thread(new Runnable(){</pre>
<pre> public void run() {</pre>
<pre> ComponentManager.getComponentManager().shutdown();</pre>
<pre>
stopHttpServer(bootstrapServer);</pre>
<pre> bootstrapServer = null;</pre>
<pre> if (adminServer!=null) {</pre>
<pre> stopHttpServer(adminServer);</pre>
<pre> adminServer = null;</pre>
<pre> }</pre>
<pre> if (indexServer!=null) {</pre>
<pre> stopHttpServer(indexServer);</pre>
<pre> indexServer = null;</pre>
<pre> }</pre>
<pre> if (searchServer!=null) {</pre>
<pre> stopHttpServer(searchServer);</pre>
<pre> searchServer = null;</pre>
<pre> }</pre>
<pre> }</pre>
<pre> });</pre>
<pre> cleanStop.setDaemon(true);</pre>
<pre> cleanStop.start();</pre>
<pre> </pre>
<pre> try {</pre>
<pre> cleanStop.join(hardRestartTimeout);</pre>
<pre> } catch (InterruptedException e) {</pre>
<pre> throw new RuntimeException(e);</pre>
<pre> }</pre>
<pre> if (cleanStop.isAlive())</pre>
<pre> logger.warn("Hard restarting AnalysisService because soft restart timed out after " + hardRestartTimeout + " millis.");</pre>
<pre> </pre>
<pre> return exitCode;</pre>
<pre> }</pre>
<pre>
</pre>
</blockquote>
<br>
<br>
<br>
Thanks for your help,<br>
<br>
Chuck<br>
<br>
<br>
Leif Mortenson wrote on 11/10/2006 08:54 PM:
<blockquote cite="mid...@ta..." type="cite">
<pre wrap="">Chuck,
A note on your large classpath. You can make your app much easier
to maintain by
changing it to the following:
wrapper.java.classpath.1=../dist/AnalysisService.jar
wrapper.java.classpath.2=../lib/*.jar
wrapper.java.classpath.3=../classes
Chuck Williams wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Leif,
Thanks for your response. My latest wrapper.conf is attached.
I user "Method 3" integration, i.e. a class that implements
WrapperListener.
Here are a couple more anomalies I've noted:
1. wrapper.restart.delay is not always honored. If the application
does Runtime.getRuntime().halt() then it works, but if the jvm
halts on its own (e.g., because of a SIGSEGV, which I was
getting for a while), or if wrapper does kill -9 on the jvm due
to a ping timeout (see below) then the restart delay is not
honored. When the restart delay is not honored, the restart
frequently does not work. This is why I've changed
wrapper.on_exit.default to RESTART, which causes the failure to
start the jvm without restart delay to then get trapped for
subsequent jvm launch. Fortunately the restart delay is then
honored and the second launch attempt succeeds.
</pre>
</blockquote>
<pre wrap=""><!---->Could you please show me an example wrapper.log with wrapper.debug=true
enabled
that shows an example of the wrapper ignoring the restart delay? I
tried the examples
that you gave me, but they all worked correctly for me.
</pre>
<blockquote type="cite">
<pre wrap=""> 1. The jvm evidently does not respond to pings during a full gc.
I've gotten cases where the jvm is waiting too long to start
full vc, with little space left. This causes an abnormally long
gc cycle, and unloads some classes (although not the ones
subject to the inner class problem), ending up taking longer
than the default 30 seconds. This is why wrapper.ping.timeout
is increased to 5 minutes.
</pre>
</blockquote>
<pre wrap=""><!---->Do you have enough physical memory to keep the entire JVM + OS in
memory without
any disk swapping? In my experience, Java gets VERY SLOW when it is
forced to do
disk swapping. Your memory settings are in
../conf/wrapper.memory.properties which
you did not send. How much memory are you using?
</pre>
<blockquote type="cite">
<pre wrap="">I'll have to do a run with wrapper debug logging until I get one of
the occasional inner class problems. I've now noted these both on
start-up and shut-down. Occasionally the app is unable to load many
classes after start-up. This appears binary. Either many classes are
missing, or all is fine. If all is fine, there is never a subsequent
problem until shutdown, when the inner class issue can arise again.
This problem first arose on the upgrade from wrapper 3.1.2 to 3.2.3.
I don't believe any other changes were involved, although it could be
coincidental of course. I.e., the issue could also exist in wrapper
3.1.2.
The app does not use any native libraries other than wrapper. The
rest is pure java.
Thanks for your help! I'll post a debug log file with the inner class
issue as soon as I can generate one.
</pre>
</blockquote>
<pre wrap=""><!---->Ok, I'll take a look at your debug log when you post it.
Cheers,
Leif
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
<a class="moz-txt-link-freetext" href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642</a>
_______________________________________________
Wrapper-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wra...@li...">Wra...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/wrapper-user">https://lists.sourceforge.net/lists/listinfo/wrapper-user</a>
</pre>
</blockquote>
<br>
<div class="moz-signature"><br>
</div>
</body>
</html>
|
|
From: Leif M. <le...@ta...> - 2006-11-11 06:54:35
|
Chuck,
A note on your large classpath. You can make your app much easier
to maintain by
changing it to the following:
wrapper.java.classpath.1=../dist/AnalysisService.jar
wrapper.java.classpath.2=../lib/*.jar
wrapper.java.classpath.3=../classes
Chuck Williams wrote:
> Hi Leif,
>
> Thanks for your response. My latest wrapper.conf is attached.
>
> I user "Method 3" integration, i.e. a class that implements
> WrapperListener.
>
> Here are a couple more anomalies I've noted:
>
> 1. wrapper.restart.delay is not always honored. If the application
> does Runtime.getRuntime().halt() then it works, but if the jvm
> halts on its own (e.g., because of a SIGSEGV, which I was
> getting for a while), or if wrapper does kill -9 on the jvm due
> to a ping timeout (see below) then the restart delay is not
> honored. When the restart delay is not honored, the restart
> frequently does not work. This is why I've changed
> wrapper.on_exit.default to RESTART, which causes the failure to
> start the jvm without restart delay to then get trapped for
> subsequent jvm launch. Fortunately the restart delay is then
> honored and the second launch attempt succeeds.
>
Could you please show me an example wrapper.log with wrapper.debug=true
enabled
that shows an example of the wrapper ignoring the restart delay? I
tried the examples
that you gave me, but they all worked correctly for me.
> 1. The jvm evidently does not respond to pings during a full gc.
> I've gotten cases where the jvm is waiting too long to start
> full vc, with little space left. This causes an abnormally long
> gc cycle, and unloads some classes (although not the ones
> subject to the inner class problem), ending up taking longer
> than the default 30 seconds. This is why wrapper.ping.timeout
> is increased to 5 minutes.
>
Do you have enough physical memory to keep the entire JVM + OS in
memory without
any disk swapping? In my experience, Java gets VERY SLOW when it is
forced to do
disk swapping. Your memory settings are in
../conf/wrapper.memory.properties which
you did not send. How much memory are you using?
>
> I'll have to do a run with wrapper debug logging until I get one of
> the occasional inner class problems. I've now noted these both on
> start-up and shut-down. Occasionally the app is unable to load many
> classes after start-up. This appears binary. Either many classes are
> missing, or all is fine. If all is fine, there is never a subsequent
> problem until shutdown, when the inner class issue can arise again.
>
> This problem first arose on the upgrade from wrapper 3.1.2 to 3.2.3.
> I don't believe any other changes were involved, although it could be
> coincidental of course. I.e., the issue could also exist in wrapper
> 3.1.2.
>
> The app does not use any native libraries other than wrapper. The
> rest is pure java.
>
> Thanks for your help! I'll post a debug log file with the inner class
> issue as soon as I can generate one.
Ok, I'll take a look at your debug log when you post it.
Cheers,
Leif
|
|
From: Chuck W. <ch...@ma...> - 2006-11-11 02:27:46
|
### ***** ### This file is automatically generated from ../conf/wrapper.conf.template ### DO NOT EDIT THIS FILE directly as your changes will be lost ### ***** #******************************************************************** # MetaLINCS Analysis Service Start-up configuration # #******************************************************************** # Java Application wrapper.java.command=java # Java Main class. wrapper.java.mainclass=com.metalincs.analysis.framework.Main # Java Classpath wrapper.java.classpath.1=../dist/AnalysisService.jar wrapper.java.classpath.2=../lib/activation-1.1.jar wrapper.java.classpath.3=../lib/annogen-0.1.0.jar wrapper.java.classpath.4=../lib/ant-1.6.5.jar wrapper.java.classpath.5=../lib/ant.jar wrapper.java.classpath.6=../lib/axiom-api-SNAPSHOT.jar wrapper.java.classpath.7=../lib/axiom-dom-SNAPSHOT.jar wrapper.java.classpath.8=../lib/axiom-impl-SNAPSHOT.jar wrapper.java.classpath.9=../lib/axis2-1.1-SNAPSHOT.jar wrapper.java.classpath.10=../lib/backport-util-concurrent-2.2.jar wrapper.java.classpath.11=../lib/bcel-5.2.jar wrapper.java.classpath.12=../lib/bcprov-jdk13-133.jar wrapper.java.classpath.13=../lib/colt.jar wrapper.java.classpath.14=../lib/commons-codec-1.3.jar wrapper.java.classpath.15=../lib/commons-collections-3.2.jar wrapper.java.classpath.16=../lib/commons-dbcp-1.2.1.jar wrapper.java.classpath.17=../lib/commons-fileupload-1.1.1.jar wrapper.java.classpath.18=../lib/commons-httpclient-3.0.1.jar wrapper.java.classpath.19=../lib/commons-io-1.2.jar wrapper.java.classpath.20=../lib/commons-lang-2.1.jar wrapper.java.classpath.21=../lib/commons-logging-1.1.jar wrapper.java.classpath.22=../lib/commons-pool-1.3.jar wrapper.java.classpath.23=../lib/concurrent-1.0.jar wrapper.java.classpath.24=../lib/concurrent.jar wrapper.java.classpath.25=../lib/crimson.jar wrapper.java.classpath.26=../lib/geronimo-spec-jms-1.1-rc4.jar wrapper.java.classpath.27=../lib/groovy-all-1.0-jsr-06.jar wrapper.java.classpath.28=../lib/incubator-activemq-4.0.1.jar wrapper.java.classpath.29=../lib/jakarta-ant-optional.jar wrapper.java.classpath.30=../lib/jakarta-httpcore-4.0-alpha2.jar wrapper.java.classpath.31=../lib/java-getopt.jar wrapper.java.classpath.32=../lib/jaxb-api-2.0.2.jar wrapper.java.classpath.33=../lib/jaxb-impl-2.0.2.jar wrapper.java.classpath.34=../lib/jaxb-xjc-2.0.2.jar wrapper.java.classpath.35=../lib/jaxen-1.1-beta-10.jar wrapper.java.classpath.36=../lib/jaxme2-0.5.2.jar wrapper.java.classpath.37=../lib/jaxmeapi-0.5.2.jar wrapper.java.classpath.38=../lib/jaxmejs-0.5.2.jar wrapper.java.classpath.39=../lib/jaxmexs-0.5.2.jar wrapper.java.classpath.40=../lib/jaxp.jar wrapper.java.classpath.41=../lib/jcert.jar wrapper.java.classpath.42=../lib/jcifs-0.9.6.jar wrapper.java.classpath.43=../lib/jcs-1.2.7.3.jar wrapper.java.classpath.44=../lib/jdbc2_0-stdext.jar wrapper.java.classpath.45=../lib/jdbc3_0-ext.jar wrapper.java.classpath.46=../lib/jibx-bind-1.1.1.jar wrapper.java.classpath.47=../lib/jibx-run-1.1.1.jar wrapper.java.classpath.48=../lib/jnet.jar wrapper.java.classpath.49=../lib/jsse.jar wrapper.java.classpath.50=../lib/jta-1.0.1B.jar wrapper.java.classpath.51=../lib/jtds-1.2.jar wrapper.java.classpath.52=../lib/junit-3.8.2.jar wrapper.java.classpath.53=../lib/jwnl-1.3.3.jar wrapper.java.classpath.54=../lib/log4j-1.2.13.jar wrapper.java.classpath.55=../lib/lucene-core-2.0-rc1-dev.jar wrapper.java.classpath.56=../lib/LuceneExtensions.jar wrapper.java.classpath.57=../lib/lucene-highlighter-2.0-rc1-dev.jar wrapper.java.classpath.58=../lib/lucene-snowball-2.0-rc1-dev.jar wrapper.java.classpath.59=../lib/mail-1.4.jar wrapper.java.classpath.60=../lib/maven-itest-plugin-1.0.jar wrapper.java.classpath.61=../lib/maxent-2.4.0.jar wrapper.java.classpath.62=../lib/mysql-connector-java-3.1.12-bin.jar wrapper.java.classpath.63=../lib/neethi-SNAPSHOT.jar wrapper.java.classpath.64=../lib/opennlp-tools-1.3.1.jar wrapper.java.classpath.65=../lib/opensaml-1.1.jar wrapper.java.classpath.66=../lib/servletapi-2.3.jar wrapper.java.classpath.67=../lib/spring-beans-1.2.8.jar wrapper.java.classpath.68=../lib/spring-context-1.2.8.jar wrapper.java.classpath.69=../lib/spring-core-1.2.8.jar wrapper.java.classpath.70=../lib/spring-web-1.2.8.jar wrapper.java.classpath.71=../lib/stax-api-1.0.1.jar wrapper.java.classpath.72=../lib/stax-utils-20060915.jar wrapper.java.classpath.73=../lib/textcat.jar wrapper.java.classpath.74=../lib/trove.jar wrapper.java.classpath.75=../lib/woden-1.0.0M6.jar wrapper.java.classpath.76=../lib/wrapper.jar wrapper.java.classpath.77=../lib/wsdl4j-1.6.1.jar wrapper.java.classpath.78=../lib/wss4j-SNAPSHOT.jar wrapper.java.classpath.79=../lib/wstx-asl-3.0.1.jar wrapper.java.classpath.80=../lib/xalan-2.7.0.jar wrapper.java.classpath.81=../lib/xbean-2.2.0.jar wrapper.java.classpath.82=../lib/xercesImpl-2.8.1.jar wrapper.java.classpath.83=../lib/xml-apis-1.3.03.jar wrapper.java.classpath.84=../lib/XmlSchema-SNAPSHOT.jar wrapper.java.classpath.85=../lib/xmlsec-1.3.0.jar wrapper.java.classpath.86=../lib/xmlunit-1.0.jar wrapper.java.classpath.87=../classes # Java Library Path (location of wrapper.dll or libwrapper.so) wrapper.java.library.path.1=../lib/native # Additional java command line parameters # Set wrapper.java.initmemory (-Xms), wrapper.java.maxmemory (-Xmx) and wrapper.java.additional.1 thru 4 for perm space and native heap allocations #include ../conf/wrapper.memory.properties # Memory management switch recommended by Sun without explanation wrapper.java.additional.5=-XX:+UseDefaultStackSize # Fixed java properties: baseDirectory for AS tree, enable assertions, log java version information wrapper.java.additional.6=-Dcom.metalincs.analysis.baseDirectory=.. wrapper.java.additional.7=-ea wrapper.java.additional.8=-showversion # Turn off forced garbage collections by rmi (set to once per day). These are only needed if garbage collection across remote pointers is required. wrapper.java.additional.9=-Dsun.rmi.dgc.server.gcInterval=86400000 wrapper.java.additional.10=-Dsun.rmi.dgc.client.gcInterval=86400000 # Log important memory events wrapper.java.additional.11=-verbose:gc # This one requires at least update 7 of java 1.5 wrapper.java.additional.12=-XX:+HeapDumpOnOutOfMemoryError # Enable debugger and monitor access to the process #include ../conf/wrapper.monitor.properties # Set startup and shutdown max allowed times wrapper.startup.timeout=300 wrapper.shutdown.timeout=60 # Ensure we have a delay before every restart since the jvm might not launch immediately after a prior termination wrapper.restart.delay=5 # Restart on all but normal exits (also works around problem where wrapper.restart.delay ignored on jvm halts like SIGSEGV) wrapper.on_exit.default=RESTART wrapper.on_exit.0=SHUTDOWN # Restart on OOM wrapper.filter.tigger.1=java.lang.OutOfMemoryError wrapper.filter.action.1=RESTART # Timeout after which the wrapper assumes the jvm is hung and restarts it (default 30 seconds was too short for some full gcs) wrapper.ping.timeout=300 # Application parameters. Add parameters as needed starting from 1 #wrapper.app.parameter.1= #******************************************************************** # Wrapper Logging Properties #******************************************************************** wrapper.debug=TRUE # Log the generated command line at this level wrapper.java.command.loglevel=INFO # Format of output for the console. (See docs for formats) wrapper.console.format=LPDTM # Log Level for console output. (See docs for log levels) wrapper.console.loglevel=INFO # Log file to use for wrapper output logging. wrapper.logfile=../logs/wrapper.log # Format of output for the log file. (See docs for formats) wrapper.logfile.format=LPDTM # Log Level for log file output. (See docs for log levels) wrapper.logfile.loglevel=INFO # Maximum size that the log file will be allowed to grow to before # the log is rolled. Size is specified in bytes. The default value # of 0, disables log rolling. May abbreviate with the 'k' (kb) or # 'm' (mb) suffix. For example: 10m = 10 megabytes. wrapper.logfile.maxsize=10m # Maximum number of rolled log files which will be allowed before old # files are deleted. The default value of 0 implies no limit. wrapper.logfile.maxfiles=50 # Log Level for sys/event log output. (See docs for log levels) wrapper.syslog.loglevel=ERROR #******************************************************************** # Wrapper Windows Properties #******************************************************************** # Title to use when running as a console wrapper.console.title=MetaLINCS Analysis Service #******************************************************************** # Wrapper Windows NT/2000/XP Service Properties #******************************************************************** # WARNING - Do not modify any of these properties when an application # using this configuration file has been installed as a service. # Please uninstall the service before modifying this section. The # service can then be reinstalled. # Name of the service wrapper.ntservice.name=metalincsd # Display name of the service wrapper.ntservice.displayname=MetaLINCS Analysis Service # Description of the service wrapper.ntservice.description=MetaLINCS Analysis Service -- responds to requests from other MetaLINCS components # Service dependencies. Add dependencies as needed starting from 1 #wrapper.ntservice.dependency.1= # Mode in which the service is installed. AUTO_START or DEMAND_START wrapper.ntservice.starttype=AUTO_START # Allow the service to interact with the desktop. wrapper.ntservice.interactive=false |
|
From: Chuck W. <ch...@ma...> - 2006-11-11 02:20:26
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Leif,<br>
<br>
Thanks for your response. My latest wrapper.conf is attached.<br>
<br>
I user "Method 3" integration, i.e. a class that implements
WrapperListener.<br>
<br>
Here are a couple more anomalies I've noted:<br>
<ol>
<li>wrapper.restart.delay is not always honored. If the application
does Runtime.getRuntime().halt() then it works, but if the jvm halts on
its own (e.g., because of a SIGSEGV, which I was getting for a while),
or if wrapper does kill -9 on the jvm due to a ping timeout (see below)
then the restart delay is not honored. When the restart delay is not
honored, the restart frequently does not work. This is why I've
changed wrapper.on_exit.default to RESTART, which causes the failure to
start the jvm without restart delay to then get trapped for subsequent
jvm launch. Fortunately the restart delay is then honored and the
second launch attempt succeeds.<br>
<br>
</li>
<li>The jvm evidently does not respond to pings during a full gc.
I've gotten cases where the jvm is waiting too long to start full vc,
with little space left. This causes an abnormally long gc cycle, and
unloads some classes (although not the ones subject to the inner class
problem), ending up taking longer than the default 30 seconds. This is
why wrapper.ping.timeout is increased to 5 minutes.</li>
</ol>
<br>
I'll have to do a run with wrapper debug logging until I get one of the
occasional inner class problems. I've now noted these both on start-up
and shut-down. Occasionally the app is unable to load many classes
after start-up. This appears binary. Either many classes are missing,
or all is fine. If all is fine, there is never a subsequent problem
until shutdown, when the inner class issue can arise again.<br>
<br>
This problem first arose on the upgrade from wrapper 3.1.2 to 3.2.3. I
don't believe any other changes were involved, although it could be
coincidental of course. I.e., the issue could also exist in wrapper
3.1.2.<br>
<br>
The app does not use any native libraries other than wrapper. The rest
is pure java.<br>
<br>
Thanks for your help! I'll post a debug log file with the inner class
issue as soon as I can generate one.<br>
<br>
Chuck<br>
<br>
<br>
Leif Mortenson wrote on 11/10/2006 02:06 PM:
<blockquote cite="mid...@ta..." type="cite">
<pre wrap="">Chuck,
What integration method are you using? There were some minor
changes to the
WrapperStartStopApp concerning how it decides when to shutdown the JVM.
I don't
think that should have done anything to cause the problems you are seeing.
There are not any other changes that I can think of that could
possibly be causing
the problems you are seeing.
Were there any other changes to your application other than the
upgrade from 3.1.2
to 3.2.3?
Could you post your full wrapper.conf and a wrapper.log file with
wrapper.debug=true?
I may be able to get some clues from them.
Cheers,
Leif
Chuck Williams wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The problem appears to be worse than described below. It appears that
certain inner classes are not loaded properly. I've only seen this
since upgrading to wrapper 3.2.3 from 3.1.2 Does wrapper do something to
affect class loading? Has anybody else experienced problems accessing
inner classes?
Thanks for any help,
Chuck
Chuck Williams wrote on 10/29/2006 11:19 AM:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
After recently upgrading from wrapper 3.1.2 to 3.2.3 an anomaly has
developed in my application. When a normal kill signal is received on
linux (e.g., control-c when running from console) and
WrapperListener.stop() is called, occasionally classes are unloaded too
early, causing subsequent references to those classes in my shutdown
code to get NoClassDefFoundError. One time an inner class in my stop()
method itself got this error!
Can anyone explain or suggest a solution? Has anyone else seen this?
Thanks for any help,
Chuck
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
<a class="moz-txt-link-freetext" href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642</a>
_______________________________________________
Wrapper-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wra...@li...">Wra...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/wrapper-user">https://lists.sourceforge.net/lists/listinfo/wrapper-user</a>
</pre>
</blockquote>
<br>
</body>
</html>
|
|
From: Mehul N. S. <meh...@gm...> - 2006-11-11 01:54:21
|
Leif,
Sorry about that. I've attached my wrapper-geronimo.conf file and am
also including my wrapper-geronimo.log file with the wrapper.debug=true
property set. The wrapper-geronimo.log file has a 'wrapper -t' followed by a
'wrapper -q' followed by a 'wrapper -c'. Despite having
wrapper.logfile.loglevel=DEBUG, I did not get any DEBUG information when I was
starting the service using 'wrapper -t'.
How do I set environment variables for the service ? I don't think I
saw anything in the documentation about a property to do that.
cheers,
mehul
Leif Mortenson said the following on 11/10/2006 5:49 PM:
> Mehul,
> The best place to look for the cause is your wrapper.log file. In
> most cases, the
> problem is pretty obvious. I am not able to make many guesses without
> seeing your
> geronimo.conf file. (It wasn't attached).
>
> If the application is working correctly in console mode, but failing
> as a service, the
> cause is most likely an environment problem. The most common causes are
> due to
> differences in the PATH and JAVA_HOME environment variables. When running
> as a console, you will be running as the user you are logged in as.
> When running as
> a service however, you will be running as the SYSTEM user by default.
>
> If you set wrapper.debug=true in your conf file, you will get even
> more detailed info
> in your wrapper.log file.
>
> Cheers,
> Leif
>
> Mehul N. Sanghvi wrote:
>> 'allo,
>>
>> I came across JWS a couple of days ago because I was looking for
>> a way to start up Apache Geronimo as a service on Windows XP Pro. It
>> took me a couple of days to figure out the wrapper.conf that I had
>> come across on Google, and using the documentation on the JWS website,
>> have managed to get things to the point where I can start Geronimo for
>> the console.
>>
>> Trying to start it as a service though does not seem to be
>> working. It just seems to stop unexpectedly. I am not sure if it is
>> JWS, or Geronimo or WinXP. I am attaching my conf file for wrapper
>> (geronimo.conf), and can provide logs if needed.
>>
>> Here is what I do to start the service:
>>
>>
>> wrapper.exe -t ..\conf\geronimo.conf
>>
>> which does tell me that it started successfully. Then when I
>> do a query
>>
>> wrapper.exe -q ..\conf\geronimo.conf
>>
>> it shows that the service is not running. Doing a "net start"
>> to see what services are running also does not show the service as
>> running. Geronimo takes a little while to start up, so I have already
>> set the time-out delay settings that I gathered from the
>> documentation. Doesn't seem to be related to that. Anyway to get
>> information as to what is happening when the service is starting ?
>>
>>
>> cheers,
>>
>> mehul
>>
>>
>
>
--
Mehul N. Sanghvi
email: meh...@gm...
|
|
From: Leif M. <le...@ta...> - 2006-11-11 00:06:15
|
Chuck,
What integration method are you using? There were some minor
changes to the
WrapperStartStopApp concerning how it decides when to shutdown the JVM.
I don't
think that should have done anything to cause the problems you are seeing.
There are not any other changes that I can think of that could
possibly be causing
the problems you are seeing.
Were there any other changes to your application other than the
upgrade from 3.1.2
to 3.2.3?
Could you post your full wrapper.conf and a wrapper.log file with
wrapper.debug=true?
I may be able to get some clues from them.
Cheers,
Leif
Chuck Williams wrote:
> The problem appears to be worse than described below. It appears that
> certain inner classes are not loaded properly. I've only seen this
> since upgrading to wrapper 3.2.3 from 3.1.2 Does wrapper do something to
> affect class loading? Has anybody else experienced problems accessing
> inner classes?
>
> Thanks for any help,
>
> Chuck
>
>
> Chuck Williams wrote on 10/29/2006 11:19 AM:
>
>> Hi All,
>>
>> After recently upgrading from wrapper 3.1.2 to 3.2.3 an anomaly has
>> developed in my application. When a normal kill signal is received on
>> linux (e.g., control-c when running from console) and
>> WrapperListener.stop() is called, occasionally classes are unloaded too
>> early, causing subsequent references to those classes in my shutdown
>> code to get NoClassDefFoundError. One time an inner class in my stop()
>> method itself got this error!
>>
>> Can anyone explain or suggest a solution? Has anyone else seen this?
>>
>> Thanks for any help,
>>
>> Chuck
>>
|
|
From: Leif M. <le...@ta...> - 2006-11-11 00:00:49
|
Robey,
Pending review of your 3rd patch about removing signal handling in
the JNI code,
I only did a partial implementation of this patch. I have added support
for SIGUSR1
and SIGUSR2 exactly the same way as the SIGHUP support in 3.2.3.
"If" I remove signal support from the JNI code then the "FORWARD"
mode would
no longer make sense and it would be reused with the "CONTROL" mode
functionality
described in your patch. That way there would be no lost functionality
for users.
Cheers,
Leif
Robey Pointer wrote:
> This is the last and largest patch.
>
> We use signals on our servers to indicate certain control messages.
> For example, HUP is used to mean "reload your config files". The
> latest version of wrapper supports catching HUP (partially) so we've
> had to modify this patch a lot, but the functionality is the same. I
> think this patch may be useful to others too.
>
> A new option for signal handling is created: "CONTROL". If that's set
> as the handler for a signal, a message is sent across the control
> channel indicating the signal, and it arrives in java-land as a
> "controlEvent" with event = WrapperManager.WRAPPER_CTRL_HUP_EVENT (or
> whatever).
>
> This way, the JNI code doesn't have to try to catch signals -- only
> the wrapper process catches them, and passes them on. In addition,
> USR1 and USR2 signals are supported.
>
> robey
|
|
From: Leif M. <le...@ta...> - 2006-11-10 23:17:38
|
Robey,
Unfortunately, I can't simply remove this signal handling. There
have been cases on
Solaris where the Java process was receiving TERM signals from an
unknown source
that was leading to a shutdown. The fix was to add the ignore signals
features to the
wrapper.
Under normal operation, the wrapper and its JVM are shutdown using
signals
sent to the wrapper process. But unfortunately this is not always the
only target
of signals.
I will look into modifying this code so it does some actual
synchronization.
I didn't that code would have any problems even when not synchronized, but
I guess it does.
If you could give me some more information as to how to reproduce
this, it would
be helpful.
Cheers,
Leif
Robey Pointer wrote:
> 3rd patch of 4. This one is a little rough. Basically, under high
> load, catching signals inside JNI causes the JVM to crash, at least on
> Linux. Crashing the JVM is really bad, and basically a
> non-recoverable error for any java code.
>
> Since signals are caught by the wrapper process and passed to the JVM
> across a control channel, there is no reason for JNI code to try to
> handle signals anyway, so we just uncommented this code. This may
> need more discussion: What is this code meant to be used for?
>
> In general, my experience has been that the JVM tends to use signals
> for its own purposes, so trying to catch signals in the JVM is bad
> medicine. This is especially true for things like HUP, USR1, and USR2.
>
> robey
|
|
From: Leif M. <le...@ta...> - 2006-11-10 23:12:12
|
Robey,
Ok I made this change to the 32 and 64 bit makefiles for x86 linux
builds. The updates
are in SVN and will be in the next release.
Thanks again,
Leif
Robey Pointer wrote:
> Here's the 2nd patch; it's a trivial patch that just adds "-m" to the
> link line on Linux. Recent versions of Linux (Debian and Ubuntu, at
> minimum) don't automatically link with libm, so you have to add it
> explicitly if you want the math functions.
>
> robey
|
|
From: Leif M. <le...@ta...> - 2006-11-10 23:06:04
|
Robey,
Thanks for catching this. It has been committed and will be in the
next release.
Cheers,
Leif
Robey Pointer wrote:
> Hi there!
>
> We've been using wrapper at Danger for about a year now, and recently
> upgraded to version 3.2.3. We have a few patches that we apply, and
> with the last upgrade we had to modify those patches a lot, so I'm
> hoping to get most or all of them pushed upstream in some fashion.
>
> This first patch is pretty straightforward. The build scripts
> currently don't always pick up the local copy of 'ant' on systems that
> install an old 'ant' in the system path. This makes sure they do, and
> that 'ant' doesn't pick up its configuration from the system copy either.
>
> robey
|
|
From: Leif M. <le...@ta...> - 2006-11-10 22:49:59
|
Mehul,
The best place to look for the cause is your wrapper.log file. In
most cases, the
problem is pretty obvious. I am not able to make many guesses without
seeing your
geronimo.conf file. (It wasn't attached).
If the application is working correctly in console mode, but failing
as a service, the
cause is most likely an environment problem. The most common causes are
due to
differences in the PATH and JAVA_HOME environment variables. When running
as a console, you will be running as the user you are logged in as.
When running as
a service however, you will be running as the SYSTEM user by default.
If you set wrapper.debug=true in your conf file, you will get even
more detailed info
in your wrapper.log file.
Cheers,
Leif
Mehul N. Sanghvi wrote:
> 'allo,
>
> I came across JWS a couple of days ago because I was looking for a way to
> start up Apache Geronimo as a service on Windows XP Pro. It took me a couple
> of days to figure out the wrapper.conf that I had come across on Google, and
> using the documentation on the JWS website, have managed to get things to the
> point where I can start Geronimo for the console.
>
> Trying to start it as a service though does not seem to be working. It
> just seems to stop unexpectedly. I am not sure if it is JWS, or Geronimo or
> WinXP. I am attaching my conf file for wrapper (geronimo.conf), and can
> provide logs if needed.
>
> Here is what I do to start the service:
>
>
> wrapper.exe -t ..\conf\geronimo.conf
>
> which does tell me that it started successfully. Then when I do a query
>
> wrapper.exe -q ..\conf\geronimo.conf
>
> it shows that the service is not running. Doing a "net start" to see
> what services are running also does not show the service as running. Geronimo
> takes a little while to start up, so I have already set the time-out delay
> settings that I gathered from the documentation. Doesn't seem to be related to
> that. Anyway to get information as to what is happening when the service is
> starting ?
>
>
> cheers,
>
> mehul
>
>
|
|
From: Mehul N. S. <meh...@gm...> - 2006-11-10 21:58:05
|
'allo,
I came across JWS a couple of days ago because I was looking for a way to
start up Apache Geronimo as a service on Windows XP Pro. It took me a couple
of days to figure out the wrapper.conf that I had come across on Google, and
using the documentation on the JWS website, have managed to get things to the
point where I can start Geronimo for the console.
Trying to start it as a service though does not seem to be working. It
just seems to stop unexpectedly. I am not sure if it is JWS, or Geronimo or
WinXP. I am attaching my conf file for wrapper (geronimo.conf), and can
provide logs if needed.
Here is what I do to start the service:
wrapper.exe -t ..\conf\geronimo.conf
which does tell me that it started successfully. Then when I do a query
wrapper.exe -q ..\conf\geronimo.conf
it shows that the service is not running. Doing a "net start" to see
what services are running also does not show the service as running. Geronimo
takes a little while to start up, so I have already set the time-out delay
settings that I gathered from the documentation. Doesn't seem to be related to
that. Anyway to get information as to what is happening when the service is
starting ?
cheers,
mehul
--
Mehul N. Sanghvi
email: meh...@gm...
|
|
From: Leif M. <le...@ta...> - 2006-11-10 20:34:08
|
Daniel,
I placed an order for a 64-bit system last week so I can finally get
these 64-bit versions
built myself. I am hoping to get a new release out by the end of year.
Any notes that you could give me on how you got this working would
save me some
time once I get the new system.
There are a couple other users working on getting this working as
well so everyone
would appreciate what you learned.
Thanks,
Leif
Daniel Mace wrote:
> I needed to move my Java applications using the JSW to a Xeon based 64
> bit server running Windows Server 2003 RC2 Standard x64 Edition this
> week. Much to my dismay, there is no 64 bit Windows distribution of the
> JSW binaries. Also, I have no access to Visual Studio, which is required
> out of the box to use the 64 bit build scripts included with the JSW
> source package.
>
> Since I really, really like using JSW, I hacked up the JSW build script,
> batch files, and Windows 64bit makefiles. I was able to succesfully
> build wrapper.dll and wrapper.exe on this architecture (with a few
> warnings from cl.exe about unknown arguments) using the Microsoft
> Windows Server 2003 R2 Platform SDK (which is available for free from MS
> at
> http://www.microsoft.com/downloads/details.aspx?FamilyId=0BAF2B35-C656-4
> 969-ACE8-E4C0C0716ADB&displaylang=en).
>
> It seems to work just fine. The most important part of the modifications
> was removing the unnecessary dependencies to basetsd.h in the Visual
> Studio-generated .dep files.
>
> If anyone is interested in a set of instructions for reproducing a
> compilation under these circumstances, my modified makefiles/scripts, or
> the compiled binaries themselves, just let me know via the list and I'll
> work up some sort of distribution.
>
> Daniel Mace
> Senior Software Engineer, Payroll Integration
> benefitfocus.com
> 843-849-7476 x6393
>
|
|
From: Leif M. <le...@ta...> - 2006-11-10 20:29:54
|
Chris,
This patch looks great. It has been committed for the next release.
Eventually I want to get things working so the start delay is automatic.
Ie, it waits until the wrapper has entered the started state.
This would be possible using the wrapper.statusfile property. The
only problem there is that if I start using it from the command line by
specifying it in the sh script, it will break things for any users trying
to make use of it from the wrapper.conf file as properties set on the
command line can not be overridden.
Thank you for the donation as well. I attempted to reply but the
mail bounced. :-/
Cheers,
Leif
Chris Dance wrote:
> Hi,
>
> We've been using Java Service Wrapper as a host for a our reasonably
> complex server based print quota application ( http://www.papercut.biz/
> ) on the Windows platform for some time with great success. On Linux
> and Mac we've used in-house rc scripts and Launchd respectively.
> Recently we've hit a few 'hung server' issues on Linux. We've been very
> impressed with the reliability on Windows so we've decided to replace
> our rc scripts with Java Service Wrapper.
>
> In the process of moving across we found a few issues with the current
> sh.script.in, and also have added a few "extras" that we've found useful
> in our existing scripts. These are:
>
> 1) The use of "uname -p" raises an error or older Debian systems.
> Minor change to suppress messages on STDERR.
>
> 2) The use of "su" on RedHat causes issues as su always requests a
> password. Instead use "runuser" if it exists.
>
> 3) Some large "application server" style applications need to
> perform some initialization. It may be desirable for the RC script to
> wait for a few seconds to give the server some cpu time to initialize
> before returning, and hence continuing with other RC related tasks that
> may be running on the server. We introduced a extra "option" to
> configure this delay.
>
> A diff based on version 3.2.3 is attached, and just in case it does
> not come out in the email correctly, it can be downloaded from:
>
> http://www.papercut.biz/anonftp/pub/open-source/java-service-wrapper/java-service-wrapper.diff.tgz
>
>
> It would be great if this could be integrated into a future release.
> Also in appreciation of the developers doing all the hard work, I've
> arranged for a donation ;-)
>
>
>
> Cheers,
>
> Chris
|
|
From: Daniel M. <dan...@be...> - 2006-11-10 20:10:17
|
I needed to move my Java applications using the JSW to a Xeon based 64 bit server running Windows Server 2003 RC2 Standard x64 Edition this week. Much to my dismay, there is no 64 bit Windows distribution of the JSW binaries. Also, I have no access to Visual Studio, which is required out of the box to use the 64 bit build scripts included with the JSW source package. Since I really, really like using JSW, I hacked up the JSW build script, batch files, and Windows 64bit makefiles. I was able to succesfully build wrapper.dll and wrapper.exe on this architecture (with a few warnings from cl.exe about unknown arguments) using the Microsoft Windows Server 2003 R2 Platform SDK (which is available for free from MS at http://www.microsoft.com/downloads/details.aspx?FamilyId=3D0BAF2B35-C656-= 4 969-ACE8-E4C0C0716ADB&displaylang=3Den). It seems to work just fine. The most important part of the modifications was removing the unnecessary dependencies to basetsd.h in the Visual Studio-generated .dep files. If anyone is interested in a set of instructions for reproducing a compilation under these circumstances, my modified makefiles/scripts, or the compiled binaries themselves, just let me know via the list and I'll work up some sort of distribution. Daniel Mace Senior Software Engineer, Payroll Integration benefitfocus.com 843-849-7476 x6393 *************************************************************************= *************** BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is = intended only for the individual or entity to which it is addressed and = may contain information that is confidential and protected by law. = Unauthorized review, use, disclosure, or dissemination of this = communication or its contents in any way is prohibited and may be = unlawful. If you are not the intended recipient or a person responsible = for delivering this message to an intended recipient, please notify the = original sender immediately by e-mail or telephone, return the original = message to the original sender or to bfp...@be..., and = destroy all copies or derivations of the original message. Thank you. = (BFeComNote Rev. 08/01/2005) *************************************************************************= ************** |
|
From: Chris D. <chr...@pa...> - 2006-11-10 07:34:24
|
Hi, We've been using Java Service Wrapper as a host for a our reasonably complex server based print quota application ( http://www.papercut.biz/ ) on the Windows platform for some time with great success. On Linux and Mac we've used in-house rc scripts and Launchd respectively. Recently we've hit a few 'hung server' issues on Linux. We've been very impressed with the reliability on Windows so we've decided to replace our rc scripts with Java Service Wrapper. In the process of moving across we found a few issues with the current sh.script.in, and also have added a few "extras" that we've found useful in our existing scripts. These are: 1) The use of "uname -p" raises an error or older Debian systems. Minor change to suppress messages on STDERR. 2) The use of "su" on RedHat causes issues as su always requests a password. Instead use "runuser" if it exists. 3) Some large "application server" style applications need to perform some initialization. It may be desirable for the RC script to wait for a few seconds to give the server some cpu time to initialize before returning, and hence continuing with other RC related tasks that may be running on the server. We introduced a extra "option" to configure this delay. A diff based on version 3.2.3 is attached, and just in case it does not come out in the email correctly, it can be downloaded from: http://www.papercut.biz/anonftp/pub/open-source/java-service-wrapper/java-service-wrapper.diff.tgz It would be great if this could be integrated into a future release. Also in appreciation of the developers doing all the hard work, I've arranged for a donation ;-) Cheers, Chris -- Christopher Dance PaperCut Software Pty. Ltd. Profile: http://www.papercut.biz/company.htm#chris Weblog: http://papercut.biz/blog/author/chris/ |
|
From: Robey P. <ro...@da...> - 2006-11-07 00:48:36
|
This is the last and largest patch. We use signals on our servers to indicate certain control messages. For example, HUP is used to mean "reload your config files". The latest version of wrapper supports catching HUP (partially) so we've had to modify this patch a lot, but the functionality is the same. I think this patch may be useful to others too. A new option for signal handling is created: "CONTROL". If that's set as the handler for a signal, a message is sent across the control channel indicating the signal, and it arrives in java-land as a "controlEvent" with event = WrapperManager.WRAPPER_CTRL_HUP_EVENT (or whatever). This way, the JNI code doesn't have to try to catch signals -- only the wrapper process catches them, and passes them on. In addition, USR1 and USR2 signals are supported. robey |
165 messages has been excluded from this view by a project administrator.
