kedar wrote:
>> Today, it does not work reliably, as we discussed some time ago in
>> various bugs, and that's a show-stopper problem IMO.
>>
> Well, "asadmin start-domain" and doing a Runtime.exec() on it
> works "equally reliably", as long as the caller of "asadmin
> start-domain" does
> some due diligence (redirection of streams, e.g.).
> So, I guess I need your help in understanding
> why there is a reliability issue here.
I believe I captured most of this in my report [1].
One of the issues is that on Windows I can get the exit code from
asadmin. If I were to be able to invoke asadmin JVM process directly (or
better yet GF process directly), instead of going through the script,
then we could have avoided such a problem altogether.
Another issue is that on various systems the asadmin script exits with
mysterious error code, like 246. My current best guess is that it's
related to the weather in Santa Clara :-), but seriously, that's how
mysterious/unreproducible this bug is. Again, if there were less
intermediate layers, there are less chances of things going wrong.
Then there is an issue of GF process holding on to the pipe handles
(pipe as in OS, which are used for processes to communicate with each
other), causing a reader thread to block forever (this is why spawn
needs to be used to invoke asadmin --- much of details have slipped my
memory, but it's all captured in one of the bug reports I filed.)
Oh, one more. The deployment occasionally just hangs. It doesn't fail,
but it just won't come back. It could very well be our problem, but
having many layers makes it hard for us to diagnose the real cause.
I can hide a lot of ugly things in Cargo --- like choosing the right
script to invoke, setting up lengthy CLI options, or set up environment
variables. But those things I mentioned above leak through to users of
Cargo.
As a case in point, to this day we still haven't managed to reliably
automate Glassfish to test JAX-WS because of those problems. In
comparison, our set up with Tomcat works like a breeze.
Maybe you and me meant a different thing with the word "reliability",
but those are the issues that I'd like to see fixed relatively quickly.
> I agree and accept that
> invoking a short-lived script that invokes the long running app server
> VM needs a replacement, but I hope reliability is not at stake here.
>
> Can you point me to a location where "asadmin start-domain" works reliably
> and Runtime.exec() of it doesn't?
>
> Believe me, we understand the implications of this. Being able to start
> server in a given VM is something that we do think (a lot) about.
I'd like to come back to my original point, which is that while the
embeddable GF is an obvious goal, I suspect it takes longer to get
there. If so, I'd like to be able to reliably launch a GF in another
process in the mean time.
[1]
http://blogs.sun.com/theaquarium/entry/container_automation_glassfish_vs_tomcat
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com