[Wrapper-user] flexible memory settings

[Jeff K. <sch...@gm...>]

Hi all,

I have a somewhat unusual contraint on my application, and I am unable to=
=20
find a way to make this work with the service wrapper. Our application is=
=20
built automatically (using ant) from a code repository (cvs). The=20
wrapper.conf for the app will reside in cvs. This application runs in 3=20
different environments, development, QA, and production. The JVM memory=20
settings for each of these environments should not- cannot- be the same;=20
production has much higher amounts of memory available and allocated. Thus,=
=20
if I include the memory value settings directly in the wrapper.conf, these=
=20
will the same across all three environments, like so:
wrapper.java.initmemory=3D128
wrapper.java.maxmemory=3D256

The wrapper.conf will get pulled from the repository with these values=20
regardless of whether we're building dev, qa or prod.... does not work for=
=20
us. So I began diving into the flexibility provided by the service wrapper.=
=20
The environment variable approach seems ideal, since each environment runs=
=20
on a different box.

Option #1: Set the lines in the wrapper.conf to read from environment=20
variables:
wrapper.java.initmemory=3D%APP_MIN_MEM%
wrapper.java.maxmemory=3D%APP_MAX_MEM%
This could work for us by setting these in the user's .bashrc (linux, btw).=
=20
Except that if our sysadmin were to forget to set these when we install the=
=20
app, the service wrapper does not puke, but instead starts up with these=20
options _omitted_. Which causes the JVM to run under its default memory=20
settings, 64-128, which is the worst case possible- no one would notice=20
until we got an OutOfMemory some time later. My goal is to get the service=
=20
wrapper to puke on startup, signalling to the sysadmin that the app will no=
t=20
startup until these environment variables are defined.

Option #2 Set the values in wrapper.conf to garbage to guarantee it will=20
puke on startup unless the environment vars are set.=20
set.APP_MIN_MEM=3Dblahblahblah
set.APP_MAX_MEM=3Dblahblahblah
wrapper.java.initmemory=3D%APP_MIN_MEM%
wrapper.java.maxmemory=3D%APP_MAX_MEM%
Somehow, the wrapper is checking the validity of these arguments, and again=
=20
omitting them if they are not valid. I also tried -1 as a value, but it mus=
t=20
be doing range-checking as well. Runs under JVM defaults- won't work.

Option #3 Replace the values in the wrapper.conf at build time with token=
=20
replacement. Yet if we forget to set the build token value, the app will=20
deploy and run with the JVM defaults as in option 1. Won't work.

Option #4: Use different wrapper.conf files for dev, qa and prod, picked at=
=20
build time. Absolute last resort.


Is there some other trickiness with the environment variables I have not=20
used? Does anyone know a good way around this?

Many many thanks,
Jeff