Date: Sat, 4 May 2002 12:24:41 -0700 From: Helmut Hissen <helmut@zeebar.com> To: freebsd-java@freebsd.org Subject: java program as service Message-ID: <20020504122441.A1230@zeebar.com>
next in thread | raw e-mail | index | archive | help
going from a run-once-inside-test-environment to persistent
server brings up a number of issues, especially if you are
beating up the JVM.
I used to run Java chat servers with hunders/thousands of
IRC and HTTP connections, and every single time we switched JVMs,
some other totally bizarre and obscure thing happened, never right
away tho, but only after running for 6 hours and only at 2am
and especially on holidays :-).
starting through rc.d is fine, but consider this...
- get the user/group and file protections right, especially
if you are planning to access or create files incl log files
in various places, and think about how you are planning to
clean them up
- if you write your own service and its open to the world,
make sure you dont open the flood gates to hackers. most
existing network services out there have had the benefit
of having been hacked-into and fixed a few times (and being
hardened as a result).
- get you path, and CLASSPATH right. you wont be able to
rely on your .{c,ba}shrc you tested with, but its nice to
make that stuff explicit anyways
- you may discover that you forgot to close a file somewhere
in the code and/or that you are hanging on to more objects
than you realize. this is where good logging and debugging
hooks comes in handy.
- if you are keeping the Java process around, and you are
giving it an ongoing good workout, you may join the league
of people who get to deal with the ever-evolving JVM
bug-du-jour.
- depending on the OS and system kernel parameters, you may run
into process limits (max # of open files)
- the JVM may well die after a while, depending on which one
and what you are doing to it. best to assume that will hapen
and run your service from a non-Java wrapper script, (csh, sh,
tclsh, perl) that goes something like this:
set path/classpath
set per-process limits
while (true) {
save previous logfile
java ...... >& logfile
if (being shutdown)
exit
email cause-of-death to cell phone / pager
}
- keep a backup copy of the JDK and OS so that if you need to
reinstall you wont be hostage to JVM-bug-du-jour on the new
JVM/OS combination
- we used to run a watchdog thread whose only job was to wake up
at a scheduled time. it would then look at the clock and if it
woke up late, it would send out a warning. The freequency of
these warnings turned out to be one of the best indicators for
impending user-visible trouble.
I alluded to "obscure problems" you are more likely to run into
in a persistent server... here are two particular annoying examples
of ther kind of things I have run into in the past:
- JVM did not properly close sockets if the connection was
terminated by certain errors (even though our application code
released the associated objects), causing process to run out
of file descriptors after a few days..
- forking image utilities as subprocess from Java server
(specifically, exit of the spawned process) caused a completely
unrelated thread to wake up from a sleep, but only after a couple
of hours of server uptime when things got really busy and during
garbage collection.
seems like every JVM we tried had some such quirk, no matter what
color threads, and you would only run into this only on a fullmoon
and you're about to go out to have dinner with someone special.
sorry for ranting a bit ... I hope you wont run into anything
particularly annoying. chances are you wont. may your special
dinners be uninterrupted.
cheers
Helmut Hissen
helmut@dialabc.com
>hello!
>
>if i want to run a java program as a service, how is this done in the
>best way? can i do as an ordinary service that i start through a script
>in rc.d, or is there something special i have to think about?
>
>br
>.z
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020504122441.A1230>