wrapper-user — User issues for Wrapper. (Support questions, etc.)

Re: [Wrapper-user] Problems to wrap jboss

[Gunnar S. <gu...@di...>]

 Hello,

You didn't mention the version of JBoss you were trying to wrap but I assume
it is JBoss 3.0.x.
The attached config works fine for us with JBoss 3.0.3 and 3.0.4.
Hope you can resolve your problem.

Regards,
Gunnar Stefansson
Dimonsoftware

P.s. Wrapper version we use with this config is 2.2.8

----- Original Message -----
From: "Mark Striebeck" <mar...@we...>
To: <wra...@li...>
Sent: Sunday, February 02, 2003 5:24 AM
Subject: [Wrapper-user] Problems to wrap jboss


> Hi,
>
> I was trying to use the Java Service Wrapper for Jboss. But for some
> reasons I don't seem to be able to get the .conf file correct. It seems
> to be a problem with the wrapper.app.parameter settings.
>
> If someone has a .conf file, can he/she please post it.
>
> Or where can I get some more information about the wrapper.app.parameter
> settings? The docu has tomcat as an example, but I can't use that for
jboss.
>
> Thanks!!!!!
>
> MarkS
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] .NET Platform SDK

[Mikkel D. <mi...@co...>]

It is freely downloadable, as a part of the .NET Platform SDK.=20
You will also need the freely downloadable Platform SDK.

As far as I can tell, the c/c++ compiler included with the .NET platform =
SDK is not dependent on other .NET stuff.

I dont know how to make the makefile work for visual studio. My guess is =
that you should remove some of the -D from the COMPILER definition. And =
ofcourse set the build environment.

>>> le...@ta... 02/03/03 08:56am >>>
Mikkel,
    Thanks for this.  I will plead ignorance of .NET   Is this a=20
compiler that can be
downloaded.  Or is it something I would have to purchase?  One thing on=20
my list
is to move the currently manual building of the native code on windows=20
into the
ant build.   I have done it for other projects, just have to merge the=20
code into
the Wrapper build.   When I get that in, can I bring this up with you=20
again to
try to figure out a way to make the build work for both MFVC and .NET?  =
They
may be one and the same.  Hope hope.  I'll get to it soon.

Cheers,
Leif

Mikkel Damsgaard wrote:

>The .NET Platform SDK comes with a fully functional c compiler.I have =
made a
>Makefile.win32 to compile using this compiler if anyone is interested.
>
>----------------------------------
>Makefile.win32 --------------------------------------------------COMPILE =
=3D
>cl -DWIN32 -D_CRTAPI1=3D""
>
>INCLUDE=3D$(INCLUDE);$(JAVA_HOME)/include;$(JAVA_HOME)/include/win32
>
>wrapper_SOURCE =3D wrapper.c wrapper_win.c property.c logger.c
>
>wrapper_dll_SOURCE =3D wrapperjni_win.c wrapperjni.c
>
>BIN =3D ../../bin
>DLLDIR =3D ../../lib
>
>all: wrapper wrapper.dll
>
>clean:
> rm -f *.o $(BIN)/realpath $(BIN)/wrapper
>cleanall: clean
> rm -rf *~ .deps
>
>wrapper: $(wrapper_SOURCE)
> $(COMPILE) $(wrapper_SOURCE) -o $(BIN)/wrapper /link shlwapi.lib
>Advapi32.lib ws2_32.lib
>
>wrapper.dll: $(wrapper_dll_SOURCE)
> $(COMPILE) $(wrapper_dll_SOURCE) /LD -o $(DLLDIR)/wrapper.dll
>
>%.o: %.c
> @echo '$(COMPILE) -c $<'; \
> $(COMPILE) -c $<
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
>http://www.vasoftware.com=20
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...=20
>https://lists.sourceforge.net/lists/listinfo/wrapper-user=20
>
> =20
>




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
http://www.vasoftware.com=20
_______________________________________________
Wrapper-user mailing list
Wra...@li...=20
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] .NET Platform SDK

[Leif M. <le...@ta...>]

Mikkel,
    Thanks for this.  I will plead ignorance of .NET   Is this a 
compiler that can be
downloaded.  Or is it something I would have to purchase?  One thing on 
my list
is to move the currently manual building of the native code on windows 
into the
ant build.   I have done it for other projects, just have to merge the 
code into
the Wrapper build.   When I get that in, can I bring this up with you 
again to
try to figure out a way to make the build work for both MFVC and .NET?  They
may be one and the same.  Hope hope.  I'll get to it soon.

Cheers,
Leif

Mikkel Damsgaard wrote:

>The .NET Platform SDK comes with a fully functional c compiler.I have made a
>Makefile.win32 to compile using this compiler if anyone is interested.
>
>----------------------------------
>Makefile.win32 --------------------------------------------------COMPILE =
>cl -DWIN32 -D_CRTAPI1=""
>
>INCLUDE=$(INCLUDE);$(JAVA_HOME)/include;$(JAVA_HOME)/include/win32
>
>wrapper_SOURCE = wrapper.c wrapper_win.c property.c logger.c
>
>wrapper_dll_SOURCE = wrapperjni_win.c wrapperjni.c
>
>BIN = ../../bin
>DLLDIR = ../../lib
>
>all: wrapper wrapper.dll
>
>clean:
> rm -f *.o $(BIN)/realpath $(BIN)/wrapper
>cleanall: clean
> rm -rf *~ .deps
>
>wrapper: $(wrapper_SOURCE)
> $(COMPILE) $(wrapper_SOURCE) -o $(BIN)/wrapper /link shlwapi.lib
>Advapi32.lib ws2_32.lib
>
>wrapper.dll: $(wrapper_dll_SOURCE)
> $(COMPILE) $(wrapper_dll_SOURCE) /LD -o $(DLLDIR)/wrapper.dll
>
>%.o: %.c
> @echo '$(COMPILE) -c $<'; \
> $(COMPILE) -c $<
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

Re: [Wrapper-user] One more patch...

[Leif M. <le...@ta...>]

Christian,
    This is a good idea, but I would like to avoid adding complexity to 
the command
line.  How would you feel about adding a section like the following to 
the primary
wrapper.conf:

wrapper.include.1=../conf/wrapperbar.conf
wrapper.include.2=../conf/wrapperfoo.conf

    The files mentioned in the include section would then be read in if 
they existed.
Any properties that had already been set would then be overridden.

    Properties specified on the command line would be set before include 
files.
This would make it possible to set an include file from the command line 
using
the standard mechanism for setting configuration properties.  You would not
be able to nest includes.

    Would something like this work for you?

    I decided to rename the 2.3.0 release to 3.0.0 because there are several
significant changes.  (Hopefully all compatible)

    The list of new features just keeps on growing for this release.  I 
have 2 or 3
other features that need to make it in as well, but all this has caused this
release to slip quite a ways already.   I will look at adding this, but 
it might end
up in a 3.0.1 release.

Cheers,
Leif

Christian Beedgen wrote:

>hi there -- lot's of cool stuff recently! I understand there is a
>release coming up soon, so here is something that I personally find very
>useful: cascading configurations. if there is interest, I would be
>delighted to see this included in the upcoming version.
>
>cascading configurations: very simple hack, basically it allows to
>specify additional configuration files that are loaded after the main
>configuration file. if an additional configuration file specifies a
>property that is already specified, the value is replaced with the value
>from the additional configuration file. if the property hasn't been
>specified, it is simply added.
>
>this is very useful if you have to query for certain parameters upon
>installation of an app (via an installer or wizard) -- instead of
>rewriting the config file, everything that has been queried from the
>user can simply be put in an additional configuration file. this also
>helps to a certain degree for upgrading, ie. a new base configuration
>file can be shipped, but changes that have already been made to an
>existing installation will remain in the additional configuration and
>don't get lost (as long as the format of the properties does not
>drastically change, that is, but still...). it's also useful if you have
>to deal with different JVMs (for example IBM on AIX, Sun on Linux),
>since for example -server as a JVM parameter makes the IBM JVM very
>unhappy from my experience.
>
>here is how this works in my implementation:
>
>./wrapper ../conf/wrapper.conf include.1=../user.conf.1
>include.2=../user.conf.2 
>
>and so on. the order that additional configuration properties are
>applied is (of course) include.1, include.2, ...
>
>attached are 4 files (wrapper.h, wrapper.c, wrapper_unix.c,
>wrapper_win.c) that are changed to implement the described
>functionality. the implementation is quick and dirty, but works for me.
>it was originally done against 2.2.9, but I just got the latest beta for
>2.3.0 (link was in Leif's mail from Mon, 20 Jan 2003 19:39:03 +0900) and
>moved the changes over there -- this is hopefully making it easier to
>diff against the current version of the code (plus my 2.2.9 was polluted
>by other stuff; also, I'm sorry for being too stupid and lazy to learn
>how to use diff and patch). since I can make very good use of this
>functionality, I would be happy to see this going into the codebase --
>this safes me from having to maintain a private fork ;) -- I am neither
>in love with my implementation nor with the names I chose for functions
>and parameters, so feel free to change all that to comply with your
>naming scheme and general ideas if you want.
>
>
>thanks,
>
>
>chr.
>  
>

[Wrapper-user] Re: Problems to wrap jboss

[Andrew C. <and...@ya...>]

Mark

Also look here, where I posted a zip file with a .conf file:

http://jboss.org/forums/thread.jsp?forum=61&thread=26031


=====
Andrew Collins - and...@ya...
http://profiles.yahoo.com/andrewrcollins/

[Wrapper-user] One more patch...

[Christian B. <kr...@di...>]

hi there -- lot's of cool stuff recently! I understand there is a
release coming up soon, so here is something that I personally find very
useful: cascading configurations. if there is interest, I would be
delighted to see this included in the upcoming version.

cascading configurations: very simple hack, basically it allows to
specify additional configuration files that are loaded after the main
configuration file. if an additional configuration file specifies a
property that is already specified, the value is replaced with the value
from the additional configuration file. if the property hasn't been
specified, it is simply added.

this is very useful if you have to query for certain parameters upon
installation of an app (via an installer or wizard) -- instead of
rewriting the config file, everything that has been queried from the
user can simply be put in an additional configuration file. this also
helps to a certain degree for upgrading, ie. a new base configuration
file can be shipped, but changes that have already been made to an
existing installation will remain in the additional configuration and
don't get lost (as long as the format of the properties does not
drastically change, that is, but still...). it's also useful if you have
to deal with different JVMs (for example IBM on AIX, Sun on Linux),
since for example -server as a JVM parameter makes the IBM JVM very
unhappy from my experience.

here is how this works in my implementation:

./wrapper ../conf/wrapper.conf include.1=../user.conf.1
include.2=../user.conf.2 

and so on. the order that additional configuration properties are
applied is (of course) include.1, include.2, ...

attached are 4 files (wrapper.h, wrapper.c, wrapper_unix.c,
wrapper_win.c) that are changed to implement the described
functionality. the implementation is quick and dirty, but works for me.
it was originally done against 2.2.9, but I just got the latest beta for
2.3.0 (link was in Leif's mail from Mon, 20 Jan 2003 19:39:03 +0900) and
moved the changes over there -- this is hopefully making it easier to
diff against the current version of the code (plus my 2.2.9 was polluted
by other stuff; also, I'm sorry for being too stupid and lazy to learn
how to use diff and patch). since I can make very good use of this
functionality, I would be happy to see this going into the codebase --
this safes me from having to maintain a private fork ;) -- I am neither
in love with my implementation nor with the names I chose for functions
and parameters, so feel free to change all that to comply with your
naming scheme and general ideas if you want.


thanks,


chr.

Re: [Wrapper-user] Re: Defining enviroment variable on the command line.

[Mikkel D. <mi...@co...>]

> Couldn't you modify the script which installs the service so that the
> replacement is done
> within the script rather than in the conf file.  I have always done it
> as follows:  If you place
> this in your script:
>
> ---
> set APP_HOME=C:\app
> set JAVA_HOME=C:\jdk1.3
> wrapper -i %APP_HOME%\wrapper.conf
wrapper.java.command=%JAVA_HOME%\bin\java
> ---
>
> Then the replacements all happen in the script so the parameters passed
> to the wrapper
> are all replaced.  The full command that is then stored in the registry
> looks like this:
> ---
> wrapper -s C:\app\wrapper.conf wrapper.java.command=C:\jdk1.3\bin\java
> ---
> At run time no environment variables are used so things work correctly.
>  This should give
> you the exact same functionality as you are requesting?
>

I could, but I wont be able to use %APP_HOME% in the .conf file, and I will
have to specify everything
depending on %APP_HOME% on the comand line. In my case about 10-15
variables, such as
java.classpath stuff. Besides when changing the classpath, you I will have
to reinstall the service
for it to take effect.

/Mikkel

> Cheers,
> Leif
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Problems to wrap jboss

[Leif M. <le...@ta...>]

Mark,
    Take a look at the following thread:
https://sourceforge.net/forum/message.php?msg_id=1509406
    If that doesn't help, then can you please post your conf file as well as
the output of a single launch attempt with debug output enabled.
(Set wrapper.console.loglevel=DEBUG in the conf file)

    I don't have enough info to know what is wrong yet.

Cheers,
Leif

Mark Striebeck wrote:

> Hi,
>
> I was trying to use the Java Service Wrapper for Jboss. But for some 
> reasons I don't seem to be able to get the .conf file correct. It 
> seems to be a problem with the wrapper.app.parameter settings.
>
> If someone has a .conf file, can he/she please post it.
>
> Or where can I get some more information about the 
> wrapper.app.parameter settings? The docu has tomcat as an example, but 
> I can't use that for jboss.
>
> Thanks!!!!!
>
>     MarkS
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Problems to wrap jboss

[Mark S. <mar...@we...>]

Hi,

I was trying to use the Java Service Wrapper for Jboss. But for some 
reasons I don't seem to be able to get the .conf file correct. It seems 
to be a problem with the wrapper.app.parameter settings.

If someone has a .conf file, can he/she please post it.

Or where can I get some more information about the wrapper.app.parameter 
settings? The docu has tomcat as an example, but I can't use that for jboss.

Thanks!!!!!

	MarkS

Re: [Wrapper-user] Re: Defining enviroment variable on the command line.

[Leif M. <le...@ta...>]

Mikkel Damsgaard wrote:

>When I test my program running as a service I can not have a script starting
>it. It is started
>by the service manager and not in a command prompt. If I change an
>environment variable in windows, my program (running as a service) wont be
>able to see until i reboot windows. This is true for NT, 2000 and XP.
>
>If I specify wrapper.java.additional.1 on the command line, I can not use it
>in the wrapper.conf file as
>%JAVA_HOME% in defining fx wrapper.java.command=%JAVA_HOME%/bin/java !
>
Couldn't you modify the script which installs the service so that the 
replacement is done
within the script rather than in the conf file.  I have always done it 
as follows:  If you place
this in your script:

---
set APP_HOME=C:\app
set JAVA_HOME=C:\jdk1.3
wrapper -i %APP_HOME%\wrapper.conf wrapper.java.command=%JAVA_HOME%\bin\java
---

Then the replacements all happen in the script so the parameters passed 
to the wrapper
are all replaced.  The full command that is then stored in the registry 
looks like this:
---
wrapper -s C:\app\wrapper.conf wrapper.java.command=C:\jdk1.3\bin\java
---
At run time no environment variables are used so things work correctly. 
 This should give
you the exact same functionality as you are requesting?

Cheers,
Leif

[Wrapper-user] Re: Defining enviroment variable on the command line.

[Mikkel D. <mi...@co...>]

When I test my program running as a service I can not have a script starting
it. It is started
by the service manager and not in a command prompt. If I change an
environment variable in windows, my program (running as a service) wont be
able to see until i reboot windows. This is true for NT, 2000 and XP.

If I specify wrapper.java.additional.1 on the command line, I can not use it
in the wrapper.conf file as
%JAVA_HOME% in defining fx wrapper.java.command=%JAVA_HOME%/bin/java !

/Mikkel
----- Original Message -----
From: "Leif Mortenson" <le...@ta...>
To: "Wrapper User List" <wra...@li...>
Sent: Saturday, February 01, 2003 5:00 AM
Subject: Re: Defining enviroment variable on the command line.


> Mikkel,
>     Thanks for your work here.   But I think there are already a couple
> ways to handle
> this. :-)
>
>     To set an environment variable on Windows or Unix, the typical
> method is to
> simply set the variable in the script file used to launch the Wrapper.
>  Something
> like this:
>
> ---
> set JAVA_HOME=C:\devtools\jdk1.4.1
> set PROJECT_HOME=c:\myproject\sompath
> wrapper.exe -i c:\myproject\somepath\conf\wrapper.conf
> ---
>
> If you only need to see the environment variables from within Java, then
> a second way of doing this is to either set the variables in the
> wrapper.conf
> file:
> ---
> wrapper.java.additional.1=-DJAVA_JOME=C:\devtools\jdk1.4.1
> wrapper.java.additional.2=-DPROJECT_HOME=c:\myproject\sompath
> ---
>
> Or you can do the same thing from the command line, if that is what you
> prefer:  (All one line )
> ---
> wrapper.exe -i c:\myproject\somepath\conf\wrapper.conf
> wrapper.java.additional.1=-DJAVA_JOME=C:\devtools\jdk1.4.1
> wrapper.java.additional.2=-DPROJECT_HOME=c:\myproject\sompath
> ---
>
> What version of Windows are using?  In the NT based windows
> versions (2000, XP)  You simply have to open up a new command
> prompt after changing system wide environment variables.  Existing
> command prompts will be unaffected.
>
> Cheers,
> Leif
>
> Mikkel Damsgaard wrote:
>
> > I hacked the wrapper_win.c code to add support for a -d option, to
define
> > additional environment variable on the command line to wrapper.
> >
> > ie:
> >
> > wrapper -i c:\myproject\somepath\conf\wrapper.conf wrapper.debug=true
> > -d:PROJECT_HOME=c:\myproject\sompath -d:JAVA_HOME=C:\devtools\jdk1.4.1
> >
> > where the order of arguments after the config file is irrelevant.
> >
> > The main reason for this is that when developing under windows I have
> > to reboot the machine before the services "sees" changes in
> > environment variables
> > and it is much more convenient to specify it at the command line to
> > wrapper.
> >
> > Futhermore I have several similar services running and it is nice to
> > be able to change
> > behaviour based on variables set on the commandline.
> >
> > What do you think?
> >
> > /Mikkel
> >
> > Attached: modified version of wrapper_win.c and also Makefile.win32
> >
>
>
>
>

[Wrapper-user] Re: Defining enviroment variable on the command line.

[Leif M. <le...@ta...>]

Mikkel,
    Thanks for your work here.   But I think there are already a couple 
ways to handle
this. :-)

    To set an environment variable on Windows or Unix, the typical 
method is to
simply set the variable in the script file used to launch the Wrapper. 
 Something
like this:

---
set JAVA_HOME=C:\devtools\jdk1.4.1
set PROJECT_HOME=c:\myproject\sompath
wrapper.exe -i c:\myproject\somepath\conf\wrapper.conf
---

If you only need to see the environment variables from within Java, then
a second way of doing this is to either set the variables in the 
wrapper.conf
file:
---
wrapper.java.additional.1=-DJAVA_JOME=C:\devtools\jdk1.4.1
wrapper.java.additional.2=-DPROJECT_HOME=c:\myproject\sompath
---

Or you can do the same thing from the command line, if that is what you 
prefer:  (All one line )
---
wrapper.exe -i c:\myproject\somepath\conf\wrapper.conf 
wrapper.java.additional.1=-DJAVA_JOME=C:\devtools\jdk1.4.1 
wrapper.java.additional.2=-DPROJECT_HOME=c:\myproject\sompath
---

What version of Windows are using?  In the NT based windows
versions (2000, XP)  You simply have to open up a new command
prompt after changing system wide environment variables.  Existing
command prompts will be unaffected.

Cheers,
Leif

Mikkel Damsgaard wrote:

> I hacked the wrapper_win.c code to add support for a -d option, to define
> additional environment variable on the command line to wrapper.
>  
> ie:
>  
> wrapper -i c:\myproject\somepath\conf\wrapper.conf wrapper.debug=true 
> -d:PROJECT_HOME=c:\myproject\sompath -d:JAVA_HOME=C:\devtools\jdk1.4.1
>  
> where the order of arguments after the config file is irrelevant.
>  
> The main reason for this is that when developing under windows I have
> to reboot the machine before the services "sees" changes in 
> environment variables
> and it is much more convenient to specify it at the command line to 
> wrapper.
>  
> Futhermore I have several similar services running and it is nice to 
> be able to change
> behaviour based on variables set on the commandline.
>  
> What do you think?
>  
> /Mikkel
>  
> Attached: modified version of wrapper_win.c and also Makefile.win32
>  

[Wrapper-user] .NET Platform SDK

[Mikkel D. <mi...@co...>]

The .NET Platform SDK comes with a fully functional c compiler.I have made a
Makefile.win32 to compile using this compiler if anyone is interested.

----------------------------------
Makefile.win32 --------------------------------------------------COMPILE =
cl -DWIN32 -D_CRTAPI1=""

INCLUDE=$(INCLUDE);$(JAVA_HOME)/include;$(JAVA_HOME)/include/win32

wrapper_SOURCE = wrapper.c wrapper_win.c property.c logger.c

wrapper_dll_SOURCE = wrapperjni_win.c wrapperjni.c

BIN = ../../bin
DLLDIR = ../../lib

all: wrapper wrapper.dll

clean:
 rm -f *.o $(BIN)/realpath $(BIN)/wrapper
cleanall: clean
 rm -rf *~ .deps

wrapper: $(wrapper_SOURCE)
 $(COMPILE) $(wrapper_SOURCE) -o $(BIN)/wrapper /link shlwapi.lib
Advapi32.lib ws2_32.lib

wrapper.dll: $(wrapper_dll_SOURCE)
 $(COMPILE) $(wrapper_dll_SOURCE) /LD -o $(DLLDIR)/wrapper.dll

%.o: %.c
 @echo '$(COMPILE) -c $<'; \
 $(COMPILE) -c $<

Re: [Wrapper-user] native library

[Mikkel D. <mi...@co...>]

> Mikkel Damsgaard wrote:
>
> > I noticed in the repository that a new method requestThreadDump is
> > available.
> > This is great.
> >
> > But, I dont like it being implemented in the native library. I would
> > prefer it to send a message
> > to the wrapper executable and have it send a console signal to the jvm.
>
> That would also be possible.  But what do you not like about the current
> method?
> Doing it this way makes it possible for the Thread Dump functionality to
> work when
> the JVM is being run standalone.  Without the Wrapper process
> controlling it.
>

I just wished to be able to not having the native code loaded at all,
but alas, you are right, it is vital when running as a service and the user
logs of.

Thanx for the answer.

Re: [Wrapper-user] native library

[Leif M. <le...@ta...>]

Mikkel Damsgaard wrote:

> I noticed in the repository that a new method requestThreadDump is 
> available.
> This is great.
>  
> But, I dont like it being implemented in the native library. I would 
> prefer it to send a message
> to the wrapper executable and have it send a console signal to the jvm.

That would also be possible.  But what do you not like about the current 
method?
Doing it this way makes it possible for the Thread Dump functionality to 
work when
the JVM is being run standalone.  Without the Wrapper process 
controlling it.

>  Btw, when using the wrapper executable to launch my application, what 
> use is the native library
> exactly?

The native library is also used for trapping system signals and giving 
WrapperListener
implementations a chance to handle them.   The native library is 
critical on Windows
systems to prevent the JVM from being shutdown if the user logs off.

Cheers,
Leif

[Wrapper-user] native library

[Mikkel D. <mi...@co...>]

I noticed in the repository that a new method requestThreadDump is =
available.
This is great.

But, I dont like it being implemented in the native library. I would =
prefer it to send a message
to the wrapper executable and have it send a console signal to the jvm.

Btw, when using the wrapper executable to launch my application, what =
use is the native library
exactly?

/Mikkel

[Wrapper-user] (no subject)

[Mikkel D. <mi...@co...>]

Re: [Wrapper-user] Out of memory error

[Ashish G. <as...@se...>]

Ashish Gawarikar wrote:

> Leif Mortenson wrote:
>
>>
>>> This does sound like a very very good option. If something like this 
>>> is present, it will
>>> help us a lot :) 
>>
>>
>>
>> Ok, I posted a feature request to track this feature:
>> http://sourceforge.net/tracker/index.php?func=detail&aid=676599&group_id=39428&atid=425190
>> Read it over and post any comments if you would like to see things 
>> done any differently.
>>
>> Cheers,
>> Leif
>>
>>
>>
> Hi Leif,
>
> I am having the following patch to do the feature, please let me know 
> if this is okay (esp the methods wrapperRestartProcess() and 
> wrapperStopProces()).
>
> Thank you very much,
>
> Ashish
> ------------------------
>
> +    const char * prop;
> +    const char * value;
> +    char paramBuffer[128];
> +    int i = 0;
> +
>
>     if (jvmOut != -1) {
>         while (1) {
> @@ -376,6 +381,34 @@
>             if (bytesRead <= 0) {
>                 break;
>             }
> +           do {
> +                   sprintf(paramBuffer, "wrapper.filter.trigger.%d", 
> i + 1);
> +                   prop = getStringProperty(properties, paramBuffer, 
> NULL);
> +                   if (prop) {
> +                           if (strlen(prop) > 0) {
> +                                   if (strstr(readBuf, prop))
> +                                   {
> +                                           sprintf(paramBuffer, 
> "wrapper.filter.action.%d", i + 1);
> +                                           value = 
> getStringProperty(properties, paramBuffer, NULL);
> +                                           if (value) {
> +                                                   if (strlen(value) 
> > 0) {
> +                                                           if 
> (strcasecmp(value,"SHUTDOWN") == 0)
> +                                                           {
> +                                                                   
> wrapperStopRequested(1);
> +                                                           }
> +                                                           else if 
> (strcasecmp(value,"RESTART") == 0)
> +                                                           {
> +                                                                   
> wrapperRestartProcess();
> +                                                                   
> usleep(1000000); /* sleep 1 sec */
> +                                                           }
> +                                                   }
> +                                           }
> +                                   }
> +                           }
> +                   }
> +                   ++i;
> +           }while (prop);
> +
>
>
Sorry to mention that this is in the wrapper_unix.c, and the method is 
wrapperReadChildOutput().
Thanks,

Ashish

Re: [Wrapper-user] Out of memory error

[Ashish G. <as...@se...>]

Leif Mortenson wrote:

>
>> This does sound like a very very good option. If something like this 
>> is present, it will
>> help us a lot :) 
>
>
> Ok, I posted a feature request to track this feature:
> http://sourceforge.net/tracker/index.php?func=detail&aid=676599&group_id=39428&atid=425190
> Read it over and post any comments if you would like to see things 
> done any differently.
>
> Cheers,
> Leif
>
>
>
Hi Leif,

I am having the following patch to do the feature, please let me know if 
this is okay (esp the methods wrapperRestartProcess() and 
wrapperStopProces()).

Thank you very much,

Ashish
------------------------

+    const char * prop;
+    const char * value;
+    char paramBuffer[128];
+    int i = 0;
+

     if (jvmOut != -1) {
         while (1) {
@@ -376,6 +381,34 @@
             if (bytesRead <= 0) {
                 break;
             }
+           do {
+                   sprintf(paramBuffer, "wrapper.filter.trigger.%d", i 
+ 1);
+                   prop = getStringProperty(properties, paramBuffer, NULL);
+                   if (prop) {
+                           if (strlen(prop) > 0) {
+                                   if (strstr(readBuf, prop))
+                                   {
+                                           sprintf(paramBuffer, 
"wrapper.filter.action.%d", i + 1);
+                                           value = 
getStringProperty(properties, paramBuffer, NULL);
+                                           if (value) {
+                                                   if (strlen(value) > 0) {
+                                                           if 
(strcasecmp(value,"SHUTDOWN") == 0)
+                                                           {
+                                                                   
wrapperStopRequested(1);
+                                                           }
+                                                           else if 
(strcasecmp(value,"RESTART") == 0)
+                                                           {
+                                                                   
wrapperRestartProcess();
+                                                                   
usleep(1000000); /* sleep 1 sec */
+                                                           }
+                                                   }
+                                           }
+                                   }
+                           }
+                   }
+                   ++i;
+           }while (prop);
+

Re: [Wrapper-user] I have added support for HP/AIX

[Rajiv S. <wo...@ya...>]

Hi,
   I aplogize for the delay.. Here's the good news:
I tested the latest build (1.3.0d) on solaris and it works great (I only tested
the daemonization function). Thanks Leif for being so prompt..

Rajiv

--- Leif Mortenson <le...@ta...> wrote:
>   Ashish & William,
> 
> Thanks for the patches.  It took me a little while to work through all 
> the changes
> because I had already implemented the ability to daemonize the wrapper 
> as well
> as to set the pid file on all platforms.  Take a look at the new 
> sh.script.in and
> bash.script.in files for examples of how they are used.
> 
> I think I got all of your patches implemented correctly but could you 
> please download
> the following source file and try doing the following builds on the AIX 
> and HPUX
> platforms to make sure that they work correctly.
> ./build.sh
> ./build.sh release  ( should create the src and binary releases for the 
> platform )
> ./build.sh clean
> ./build.sh total-clean
> 
> You can get your hands on the latest source by doing a CVS checkout.  Or 
> if you
> prefer, I placed a copy of the source at the following URL:
> http://www.tanukisoftware.com/wrapper_2.3.0d_src_with_doc_src.tar.gz
> 
> Let me know if you find any problems,
> Cheers,
> Leif
> 
> Ashish Gawarikar wrote:
> 
> > Leif Mortenson wrote:
> >
> >> Ashish Gawarikar wrote:
> >>
> >>> But this is in the package 2.2.8 and not in 2.2.9.
> >>>
> >>> Me and my colleague have also added few bug fixes:
> >>> 1. Added run as daemon option for this wrapper to fix the problem 
> >>> that the wrapper dies when the shell exits.
> >>> 2. clean up the add_srv before binding.
> >>>
> >>> This has been tested on AIX and HP. I can send the package to the 
> >>> Admin/maintainer.
> >>>
> >>> I did rather send the full tar.gz. Let me know the email id. 
> >>
> >>
> >>
> >> Great, please send the source to me directly, not to the list.   I 
> >> will look through the changes
> >> you made and get them merged in with the trunk.   Once I have done 
> >> that, I will ask you to
> >> download the patched source again and verify that I did everything 
> >> correctly before a release.
> >>
> >> As to your additional patches:
> >> 1) I think that I already got this implemented thanks to a patch by 
> >> Rajiv a few days ago.  I would
> >> like to see how you implemented it and make and modifications necessary.
> >> 2) Could you explain to me what the "add_srv" problem was that you 
> >> had been encountering.
> >> It may be obvious from the source. 
> >
> >
> > Before doing the bind (in the wrapper.c), the code was not doing a
> > memset(&addr_srv, 0, sizeof(addr_srv));
> > to clean the addr_srv, as a result I had some problems in the bind. It 
> > would always
> >
> >
> > Here I am attaching the source (not a diff). Please let me know if 
> > this looks good.
> > Thanks,
> >
> > Ashish Gawarikar
> >
> > PS: My colleagues name is William Lee.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Wrapper-user] Out of memory error

[Leif M. <le...@ta...>]

Ashish Gawarikar wrote:

> Its not very easy to reproduce. I ran tomcat with 100 users for 100 
> iterations to do all the application
> stuff, and sometimes in a blue moon this happens.
> Our QA team is having a problem in reproducing this. 

Try setting the max memory to 32 or 48MB rather than the default 64MB. 
 Should
make it happen more easily.

Another idea is to create a class EatMemory.doIt() that simply creates a 
LinkedList
and goes into an infinite loop of creating double arrays of length 
100000 and adding
them to the list.   You should get an OutOfMemoryError pretty quickly. 
 Question is
whether or not it happens in the right place to cause Tomcat to stop 
responding.

> This does sound like a very very good option. If something like this 
> is present, it will
> help us a lot :) 

Ok, I posted a feature request to track this feature:
http://sourceforge.net/tracker/index.php?func=detail&aid=676599&group_id=39428&atid=425190
Read it over and post any comments if you would like to see things done 
any differently.

Cheers,
Leif

Re: [Wrapper-user] Out of memory error

[Ashish G. <as...@se...>]

Leif Mortenson wrote:

> Ashish Gawarikar wrote:
>
>> Thanks for the info. I have used the settings (currently I have the 
>> max set to 128 MB).
>> But the real question (may be I missed to say that), is that the JVM 
>> stops responding,
>> and the tomcat responds with a page saying "horrible exception". My 
>> question in
>> regards to that was, if the JVM does stop responding, doesnt the 
>> wrapper detect that,
>> and restart the JVM? 
>
>
> If this is easy to reproduce.  Could you please try running tomcat 
> with the Wrapper's
> debug output enabled.  My guess is that the JVM is actually fine but 
> Tomcat has had a
> critical error and it has stopped functioning.  If that is the case, 
> then it would be a bug that
> should be reported to the Tomcat team.

Its not very easy to reproduce. I ran tomcat with 100 users for 100 
iterations to do all the application
stuff, and sometimes in a blue moon this happens.
Our QA team is having a problem in reproducing this.

>
> One thing that would be possible for me to do on the Wrapper side of 
> things is to add a
> property which would would have the Wrapper search for the string
> "java.lang.OutOfMemoryError" in the stdout/stderr output of the JVM 
> and then restart
> the JVM.  It shouldn't cause that much of a performance hit, but I 
> would still want it to be
> optional.  Might as well allow users to enter their own trigger 
> string(s) while I'm at it.
> Needless to say, this would only work where output was sent to the JVM 
> console.
> These are actually problems caused by the application, but they can 
> sometimes be
> difficult to handle when the problem would need to be trapped within 
> 3rd party code.

This does sound like a very very good option. If something like this is 
present, it will
help us a lot :)

Thank you very much for the fast responses. I appreciate all the help.

Regards,

Ashish

>
> Cheers,
> Leif
>

Re: [Wrapper-user] Out of memory error

[Leif M. <le...@ta...>]

Ashish Gawarikar wrote:

> Thanks for the info. I have used the settings (currently I have the 
> max set to 128 MB).
> But the real question (may be I missed to say that), is that the JVM 
> stops responding,
> and the tomcat responds with a page saying "horrible exception". My 
> question in
> regards to that was, if the JVM does stop responding, doesnt the 
> wrapper detect that,
> and restart the JVM? 

If this is easy to reproduce.  Could you please try running tomcat with 
the Wrapper's
debug output enabled.  My guess is that the JVM is actually fine but 
Tomcat has had a
critical error and it has stopped functioning.  If that is the case, 
then it would be a bug that
should be reported to the Tomcat team.

One thing that would be possible for me to do on the Wrapper side of 
things is to add a
property which would would have the Wrapper search for the string
"java.lang.OutOfMemoryError" in the stdout/stderr output of the JVM and 
then restart
the JVM.  It shouldn't cause that much of a performance hit, but I would 
still want it to be
optional.  Might as well allow users to enter their own trigger 
string(s) while I'm at it.
Needless to say, this would only work where output was sent to the JVM 
console.
These are actually problems caused by the application, but they can 
sometimes be
difficult to handle when the problem would need to be trapped within 3rd 
party code.

Cheers,
Leif

Re: [Wrapper-user] Out of memory error

[Ashish G. <as...@se...>]

Leif Mortenson wrote:

> Ashish,
>    The Wrapper does not do anything special in the event of 
> OutOfMemoryErrors.
> This is because in most cases, while a single thread may terminate, 
> the JVM as
> a whole will continue to function.   It is actually possible to catch 
> out of memory
> errors and continue just as can be done with any other error or 
> exception.
>
>    Java by default sets a maximum memory limit of 65MB.   The Wrapper 
> preserves
> this default.  If, as in this case, you find it necessary to make use 
> of more memory then
> you can do so by passing a -Xmx64m parameter to the JVM.  The Wrapper 
> provides
> a pair of parameters to make it easier to set the maximum and initial 
> memory settings.
>    wrapper.java.initmemory=16
>    wrapper.java.maxmemory=64
>
>    I usually run Tomcat myself with only 64MB of memory.  But have a 
> few other apps
> that run with a setting of 256.  Be aware that this is the maximum 
> memory setting, the
> JVM will not use that much memory unless it is necessary.  Giving the 
> JVM more
> room to work with can make garbage collection run a little more smoothly.
>
>    The initial memory setting defines how much memory the JVM 
> allocates at startup.
> If you know that your application always takes 96MB of memory, then 
> setting this to
> a large initial value will make the app startup a little faster..
>
>    Please see the documentation for more info on these properties.
>
> Cheers,
> Leif 

Leif,

Thanks for the info. I have used the settings (currently I have the max 
set to 128 MB).
But the real question (may be I missed to say that), is that the JVM 
stops responding,
and the tomcat responds with a page saying "horrible exception". My 
question in
regards to that was, if the JVM does stop responding, doesnt the wrapper 
detect that,
and restart the JVM?

Thanks,

Ashish

Re: [Wrapper-user] Out of memory error

[Leif M. <le...@ta...>]

Ashish,
    The Wrapper does not do anything special in the event of 
OutOfMemoryErrors.
This is because in most cases, while a single thread may terminate, the 
JVM as
a whole will continue to function.   It is actually possible to catch 
out of memory
errors and continue just as can be done with any other error or exception.

    Java by default sets a maximum memory limit of 65MB.   The Wrapper 
preserves
this default.  If, as in this case, you find it necessary to make use of 
more memory then
you can do so by passing a -Xmx64m parameter to the JVM.  The Wrapper 
provides
a pair of parameters to make it easier to set the maximum and initial 
memory settings.
    wrapper.java.initmemory=16
    wrapper.java.maxmemory=64

    I usually run Tomcat myself with only 64MB of memory.  But have a 
few other apps
that run with a setting of 256.  Be aware that this is the maximum 
memory setting, the
JVM will not use that much memory unless it is necessary.  Giving the 
JVM more
room to work with can make garbage collection run a little more smoothly.

    The initial memory setting defines how much memory the JVM allocates 
at startup.
If you know that your application always takes 96MB of memory, then 
setting this to
a large initial value will make the app startup a little faster..

    Please see the documentation for more info on these properties.

Cheers,
Leif
   

Ashish Gawarikar wrote:

> Hi,
>
> I seem to get the following error in my wrapper log and the wrapper 
> doesnt seem to restart the JVM.
>
>  [ERROR] ThreadPool - -Caught exception executing 
> org.apache.tomcat.util.net.TcpWorkerThread@198fa95f, terminating 
> thread <java.lang.OutOfMemoryError>java.lang.OutOfMemoryError
>
> [ERROR] PoolTcpEndpoint - -Unexpected error 
> <java.lang.OutOfMemoryError>java.lang.OutOfMemoryError
>
> Any help regarding this would be helpful.
> I am running wrapper 2.2.8, and tomcat version 4.1.15 and java 1.3.1
>
> Thank you,
>
> Ashish
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>