dev@glassfish.java.net

Re: Running glassfish with upstart

From: Sahoo <sanjeeb.sahoo_at_oracle.com>
Date: Wed, 08 Feb 2012 19:06:12 +0530

On Wednesday 08 February 2012 06:07 PM, John Lister wrote:
> On 07/02/2012 16:07, Tom Mueller wrote:
>>
>> To see the differences, start the DAS both ways and run jinfo on the
>> process.
> I've started glassfish using the glassfish.jar file and it seems to
> work ok, but there are a couple of differences from the output of
> jinfo that I'd like to check (ignoring the user.dir and memory
> options, etc):
>
> - asadmin adds options to start agents (flashlight in this case)
I believe you can attach flashlight agent on the fly since it is built
upon btrace which allows itself to be attached on a running vm.
> - and asadmin includes some additional jars on the classpath from the
> endorsed directory as well as those required for the agents mentioned
> above
Missing endorsed jars have no impact as GlassFish uses OSGi underneath
and it does not actually rely on modules/endorsed to be set as endorsed
dir. It will only make a difference if user adds their own jars in
domain_dir/lib/endorsed/ in which case you have to set
-Djava.endorsed.dirs explicitly in command line.
>
> I'm not sure what the impact of missing these options out are - I'm
> guessing the monitoring won't work properly without the flashlight agent?
>
> Also the change in user.dir seems to be important especially if you
> are using third party jars (eg database driver). Currently I have them
> in the domain lib directory but just using the glassfish.jar file
> doesn't seem to include this in the classpath, or at least glassfish
> can't find them
Not sure what you mean here. user.dir is only useful while resolving
relative file URIs. They don't affect class loading.
>
> Finally, the only other issue I can see with using upstart is shutting
> down glassfish, I was using a "pre-stop" call to "asadmin stop-domain"
> to terminate glassfish nicely, but this kills the process forcing
> upstart to respawn it thinking it died in error. What effect if any
> does simply kill the glassfish process have - I can imagine this isn't
> good in a clustered environment - or is there a way to effectively
> shutdown the domain while leaving the process running?
>
GlassFish process is designed to handle SIGTERM signal (which is what is
issued by kill command by default). So, you can issue that signal to
kill a glassfish process. Let us know if you see any issues with that.

Sahoo