Hi Steve,
Thank you for bringing in the support perspective.
Yes, we will fix the asadmin version command to *always*
include the build id in the printed string. This, however
is not directly related to what's being proposed in this
e-mail thread. (On the output of version command itself, I can
tell you that it needs a lot of improvement -- e.g. where
is the information that tells us what Java EE spec version
a given app server is running? -- I don't find it anywhere).
The point I am not able to understand is how "asadmin version"
having an "Edition" information alone is useful for support
personnel to investigate a customer problem. It seems that it is
almost imperative that you'd need domain.xml/logs in order to ascertain
what's going wrong at a customer site. The most important
information in the version string is the build-id, followed by
the actual product version number, isn't it?
The usage profile information is more of a fluid property of the domain. It
is a way to preconfigure a domain so that administrator does not
have to do a series of steps to change the capabilities of the domain.
Once created, a domain's runtime itself does not know about what its
usage profile is.
One of the things that I did not want to happen is to go from a
2-edition-product
to a 3-profile product. In the future, the profile support can be
generalized
so that a customer can configure how the domain gets created.
Is it still too confusing? Moreover, is it confusing because of the decision
(No Platform/Enterprise Edition in version string)? We must be careful
here, because
otherwise we might be attributing some unrelated (although important) issues
to this change.
Please let me know.
Kedar
Steve Essery wrote:
> From the support point of view having a simple way of getting a
> precise indication of what a customer is running is incredibly useful
> and its quite sad at how often they really don't have a clear idea
> what they have installed - looking at this is almost looks like we'd
> need to write a script to look in the domain.xml and at the file
> system to work out what's actually being used.
>
> Its already a pain in AS 8.1 having to use --verbose just to get the
> real build number as non-verbose output is useless. Could the verbose
> information be expanded to report which profile is in use, what key
> switches such as ASQuickStartup are set to.
>
> Regards,
> Steve
>
> kedar wrote:
>> Hi Scott,
>>
>> You have valid points. But hopefully, I have answers for most of
>> them. Let me know if they satisfy you. I don't want you to get out
>> of your comfort zone, but if you are willing to accept some changes,
>> we can do better, without making you pull your hair while debugging
>> performance problems.
>>
>> Issue: Developer Profile (or PE) Domain does not have an explicit
>> way to declare that it is running QuickStartup, however
>> it has to be turned off explicitly, if desired.
>> Solution: Yes. I agree. I don't know why it was done this way. I can
>> add an explicit jvm-option to such a developer profile domain
>>
>> (<jvm-options>-Dcom.sun.enterprise.server.ss.ASQuickStartup=*true*</jvm-options>
>>
>> which will make it clear.
>> Will that help?
>>
>> Issue: Difficulty in determining if it a dev profile (PE) domain or
>> cluster/enterprise profile domain (EE) just by looking at
>> domain.xml
>> Solution: The domain.xml for a cluster aware domain always has a
>> template config
>> called "default-config". There is no place for this config
>> in the
>> developer profile domain (PE). In addition to this, PE/dev
>> domain is a
>> "single server" domain. In a 100% cases it is possible to
>> determine
>> if it is a PE domain or EE domain by just looking at these
>> two facts.
>> Is that useful?
>>
>> Issue: Well, it's not clear what the differences are, between the
>> classic PE and EE domains.
>> Solution: Well, I've tried to summarize them in the one pager for
>> profiles project.
>> Take a look at it. If it is still not clear, I'll create a
>> summary page (FAQ's)
>> that should help. For now:
>> PE/dev/cluster domains use JKS as security store,
>> EE/enterprise domains use NSS.
>> All versions have same ORB (Ken Cavanaugh: Can you please
>> confirm)?
>> PE/dev/cluster profile uses "insecure" admin HTTP listener
>> (still being implemented).
>> EE/enterprise profile uses secure admin HTTP listener, by
>> default.
>> PE/dev profile does not have GMS. EE/cluster/enterprise
>> profile domain has it. (Comes
>> by virtue of clusters).
>> Issue: What about server.log, if you replace
>> "sun-appserver-pe/ee-9.1" by "sun-appserver-9.1"
>> won't it hinder debugging from logs?
>> Solution: This is valid concern. But it is easily determined based on
>> above differences.
>> Do you want something else to be printed in the log at the
>> startup, that'll help you
>> find out what the log corresponds to?
>> Is the rotated logs a concern? If you think an indication of
>> PE/EE on every log
>> record is a must (it happens today, just by chance) then I
>> need to think more.
>> Let me know if that's the case.
>>
>> Have I missed something?
>>
>> Regards,
>> Kedar
>>
>> Scott Oaks wrote:
>>> On Fri, 2006-12-08 at 19:00, kedar wrote:
>>>
>>>
>>>> The reason Sun's official distribution has to have both installers is
>>>> because of the bundle's size considerations.
>>>>
>>>> The runtime differences that you referred to above (like Quick
>>>> Startup) are
>>>> going to remain. A developer profile domain is different from an
>>>> enterprise
>>>> profile domain in that regard.
>>>>
>>>> Is there a way in which we can reduce the confusion?
>>>> Do you have to rely on parsing the log file in order to deduce
>>>> something?
>>>>
>>>
>>> But the differences I'm concerned about (like quick startup; there used
>>> to be some ORB-related differences that may have all gone away by now;
>>> there are possibly others) are not based on the profile, they are based
>>> on the product. By default, wich no changes to the domain.xml, PE runs
>>> with QuickStart on (and nothing in the domain.xml indicates that;
>>> though
>>> you can add a flag to turn it off). By default, with no change to the
>>> domain.xml, EE runs without Quick Start (and nothing in the domain.xml
>>> indicates that either).
>>>
>>> So presently (build 26) when someone asks us to look at their
>>> performance issues and sends a domain.xml and a server.log for us to
>>> review, we can't really tell what options are on or off. And we can't
>>> ask the customer to run asadmin version if it's not going to confirm
>>> which product is in use.
>>>
>>> Perhaps that's a transitional issue. If the binaries will behave
>>> exactly
>>> the same way with exactly the same options (including no-options or
>>> default options) in the domain.xml, then the edition string isn't
>>> needed. But if the differences between the two will continue to have
>>> different behavior with similarly-configured domain.xml files, then the
>>> edition string is needed.
>>>
>>> -Scott
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>