From owner-freebsd-java Sat May 4 14: 8: 8 2002 Delivered-To: freebsd-java@freebsd.org Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (Postfix) with ESMTP id B9EE437B41A for ; Sat, 4 May 2002 14:08:02 -0700 (PDT) Received: from d1o988.telia.com (d1o988.telia.com [213.66.132.241]) by mailb.telia.com (8.11.6/8.11.6) with ESMTP id g44L7vH28211; Sat, 4 May 2002 23:07:57 +0200 (CEST) Received: from [192.168.0.101] (h84n2fls31o988.telia.com [213.67.224.84]) by d1o988.telia.com (8.10.2/8.10.1) with ESMTP id g44L7ro09784; Sat, 4 May 2002 23:07:57 +0200 (CEST) Subject: Re: java program as service From: zoidberg To: Helmut Hissen Cc: freebsd-java@FreeBSD.ORG In-Reply-To: <20020504122441.A1230@zeebar.com> References: <20020504122441.A1230@zeebar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 May 2002 00:08:06 +0300 Message-Id: <1020546490.515.6.camel@BSD-buddha.my.router> Mime-Version: 1.0 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 On Sat, 2002-05-04 at 22:24, Helmut Hissen wrote: > > 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 > thanks alot for your answer! most helpfull!! br .z To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message