From owner-freebsd-java Sat May 4 12:19:20 2002 Delivered-To: freebsd-java@freebsd.org Received: from bigbird.zeebar.com (adsl-63-202-202-75.dsl.snfc21.pacbell.net [63.202.202.75]) by hub.freebsd.org (Postfix) with SMTP id 2701437B404 for ; Sat, 4 May 2002 12:19:13 -0700 (PDT) Received: (qmail 1265 invoked by uid 1000); 4 May 2002 19:24:41 -0000 Date: Sat, 4 May 2002 12:24:41 -0700 From: Helmut Hissen To: freebsd-java@freebsd.org Subject: java program as service Message-ID: <20020504122441.A1230@zeebar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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