The new start-domain came online yesterday afternoon.
the new stop-domain has been in place for a few weeks...
If you want to compare start-domain times right now before you get the
latest build -- do this:
* time some start-domain/start-na/start-inst
* in your OS environment set NEW_LAUNCHER=true
* repeat the startups
Suveen Nadipalli wrote:
> FYI :
>
> I have the stop-domain timings from 9.1 B04 to 9.1 B24 :
>
> B04 -> Stop-Domain = 16.50 secs
> B24 -> Stop-Domain = 9.23 secs
>
> I saw a huge improvement in stop-domain in latest 9.1 builds, but
> there is not much improvement in start-domain timings. Kedar, I will
> check with you on this off-line. My setup consists of 1 cluster with 2
> instances and 1 DAS.
>
> Thanks
> -Suveen.
>
> kedar wrote:
>>
>>
>> Kohsuke Kawaguchi wrote:
>>> kedar wrote:
>>>>>
>>>>> I've been asking Glassfish guys to give me ways to start/stop the
>>>>> container more easily, but so far they haven't given it to me :-(
>>>>>
>>>> One step at a time, and we all are "GlassFish guys".
>>>> We have now eliminated few extraneous processes that asadmin
>>>> start-domain
>>>> used to create. So, the startup is a bit better.
>>>> The shutdown of the GlassFish server is even better and faster.
>>>
>>> That's a good news. Which version of GF includes this change?
>> Being tested. Shortly, there will be a notification sent.
>> The improvements to "asadmin stop-domain" are in recent builds.
>>>
>>>> (Thanks to Byron Nevins).
>>>>
>>>> Moving on to next thing -- being able to just call a method in an
>>>> existing
>>>> JVM is on our agenda. You've got to wait. If you have any
>>>> suggestions about
>>>> how it could/should be done, feel free to discuss them at
>>>> admin_at_dev.glassfish.java.net.
>>>
>>> I think the immediate goal could be just a simplified launcher
>>> script that doesn't fork more than one process and doesn't rely on
>>> million system properties (assuming that this can be done much
>>> quickly than true embedded container support) --- something as good
>>> as Tomcat, if not as good as Jetty.
>>>
>>> I say this because not being able to reliably invoke another Java
>>> process that hosts GF is the biggest show stopper right now. As long
>>> as Cargo can work reliably, I don't think people like Konsuli would
>>> mind using it, even if Cargo internally has to do some ugly stuff.
>>> It gets the job done, after all.
>>>
>> I agree. The System Properties are ugly (in this context) and they
>> simply don't go
>> away. This is a major obstacle in doing progress.
>>> 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 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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>