On 08/02/2012 13:36, Sahoo wrote:
> 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.
Ok, I don't really use the monitoring, but will see if it behaves the same.
>> - 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.
Ok
>> 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.
I have a number of 3rd party jar files in domains/domain1/lib which if I
use asadmin are picked up correctly, but when using the glassfish.jar
directly I get ClassNotFoundExceptions. This directory isn't in the
classpath in either instance and I seem to remember there is a custom
classloader that looks in here, so I'm guessing it uses the user.dir to
derive the expected location of the above lib directory, but I could be
wrong...
>>
>> 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.
I haven't seen any issues, but when stop-domain is issued, there are
entries in the log to state it is shutting down, etc whereas using
SIGTERM doesn't result in any additional output. This may be entirely
normal, but I didn't want to risk some state being corrupted do to bad
shutdown, etc
I appreciate your help
Thanks
John
--
www.pricegoblin.co.uk