When the GlassFish server is started, the AdminAdapter that listens for
asadmin subcommands is started before the server is actually ready to
process requests. So the AdminAdapter uses a CountDownLatch to wait for
the SERVER_READY event that indicates it can run asadmin subcommands.
When any command is executed, the AdminAdapter waits on this latch for
up to 20 seconds (the value is hardcoded). If the server does not become
ready within 20 seconds, the command fails with this error message.
The server startup consists of two basic phases: 1) startup of Init
services, 2) startup of Startup services.
Once the Init services are started, then "asadmin start-domain" returns.
When the Startup services have been started, then the AdminAdapter is
ready to start processing requests.
I've file issue 16204 for this:
http://java.net/jira/browse/GLASSFISH-16204
I made it an RFE, but if you'd like to reclassify this as a bug, I'd be
open to that.
Tom
On 3/14/2011 12:21 AM, Laird Nelson wrote:
> asadmin behaves VERY oddly sometimes on a Windows system.
>
> Here's a cut-and-paste from a recent command line session I just
> performed (this is batch file output):
>
> C:\LEAD\bin>set AS_ADMIN_READTIMEOUT=500000
>
> C:\LEAD\bin>call asadmin undeploy --cascade lead-1.0-SNAPSHOT
> V3 cannot process this command at this time, please wait
> Closest matching local and remote command(s):
> undeploy
> Command undeploy failed.
>
> I can't give you a test case, because this only happens sometimes. I
> have the AS_ADMIN_READTIMEOUT set to work around
> http://java.net/jira/browse/GLASSFISH-13009 and
> http://java.net/jira/browse/GLASSFISH-13242.
>
> The best I can tell you is that at the time Glassfish 3.1 final is
> running as a service, as installed by the asadmin create-service command.
>
> Can someone who is familiar with the asadmin code walk through it or
> just cast an eye over it and see if maybe something obvious in the
> sequencing could lead to this bizarre state of affairs?
>
> Thanks,
> Laird