Thanks for the input. This is helpful. As part of the work for the ad
hoc clustering feature, I'm planning to look through the code at the
various calls to isDas and try to determine what question is really
being asked. If some patterns emerge, hopefully we can modify the
ServerEnvironment interface to support asking better questions. Right
now, there is only one implementation of ServerEnvironment
(ServerEnvironmentImpl), but it may make sense to provide alternate
implementations instead to answer the questions.
I would also like to eliminate all of the "if the instance name is
'server' then I'm a DAS so behave this way" logic in GlassFish.
Instead, this must be converted into an appropriate call to
ServerEnvironment that answers a more specific question.
Another issue is the RuntimeType enum and its use in the @ExecuteOn
annotation. This isn't so much a case of code asking a question than a
declaration of the type of server environment in which to run. Not sure
what to do there yet other than adding more RuntimeTypes for additional
options (or at least one option for an unmanaged cluster instance, i.e.,
an instance that is part of a cluster but isn't being managed by a DAS).
Tom
On 4/21/2011 6:33 PM, Bill Shannon wrote:
> I generally prefer that you ask the question that you really want
> answered. Rather than asking "is it Windows?", ask "what's the
> file separator character?"
>
> The trick is often knowing what question to ask and when to ask it.
> I'm sure we've got a lot of assumptions about what can and can not be
> done on a DAS vs. an instance, not to mention the assumption that
> there are only two things - DAS and instance.
>
> If we use the "type" to select a ServerEnvironment implementation,
> and ServerEnvironment answers these questions, we still only have
> to test the different implementations we actually have, but the code
> becomes more flexible. (Yes, with the risk that new implementations
> will break existing code, but we already have that problem and worse.)
>
> Tom Mueller wrote on 04/21/2011 03:12 PM:
>> Tim,
>> Are you advocating a more fine-grain definition of roles? You make
>> good points
>> below.
>>
>> Currently, the GlassFish code calls isDas() in about 120 places. That
>> doesn't
>> count the @ExecuteOn annotations for the various commands (185 of
>> those).
>>
>> Tom
>>
>>
>> On 4/21/2011 4:49 PM, Tim Quinn wrote:
>>>
>>> On Apr 21, 2011, at 4:27 PM, Tom Mueller wrote:
>>>
>>>> Agreed. This is a tricky issue. There are two fundamentally
>>>> different ways to
>>>> deal with this:
>>>>
>>>> 1. Choose a small number of buckets (e.g., DAS, instance) and dump all
>>>> functionality into one or both buckets. (This is what we do currently)
>>>>
>>>> or
>>>>
>>>> 2. Group functions into some larger number of "roles", possibly
>>>> with the
>>>> number of roles approaching the number of functions. In this case,
>>>> the roles
>>>> are oriented towards the function like what you suggest below ("can
>>>> deploy to
>>>> domain") rather than being types of servers. And then define server
>>>> types
>>>> based on these roles. Thus the individual functions have no concept
>>>> at all of
>>>> the type of the server, and different variations of the server can
>>>> be created
>>>> by just choosing different roles.
>>>>
>>>> This latter approach is much more difficult for several reasons:
>>>>
>>>> a. A better understanding of the dependencies and
>>>> interrelationships between
>>>> functions is needed in order to choose roles.
>>>
>>> Which is not exactly a bad thing, that we understand what we're
>>> writing. ;-)
>>>
>>>> b. It is difficult to test all of the various combinations of
>>>> different roles
>>>> and that server can take on.
>>>>
>>> Yes, if all possible combinations actually exist, but will that be
>>> the case in
>>> 3.2? It seems to me that there will be a subset of all the possible
>>> combinations of roles that will actually exist. And those
>>> combinations will
>>> need to be tested whether we use fine-grained roles or
>>> coarse-grained buckets.
>>> Testing will need to make sure that each spot in the code that
>>> depends on the
>>> roles or the buckets does what it should in the combinations that do
>>> exist.
>>>
>>>> For now, I'm assuming we are going to continue along path #1.
>>>>
>>>> Tom
>>>>
>>>>
>>>> On 4/21/2011 3:19 PM, Tim Quinn wrote:
>>>>> Tom,
>>>>>
>>>>> As you alluded to earlier, I think, we will need to be a little
>>>>> cautious in
>>>>> how we deal with this. There are probably various aspects of
>>>>> server behavior
>>>>> that, up until now, have been grouped into "DAS" vs. "non-DAS."
>>>>> Various bits
>>>>> of code which use xxx.isDas() or other techniques might actually be
>>>>> interested in different of these aspects.
>>>>>
>>>>> For example, is this server capable of deploying an app? While in
>>>>> the past
>>>>> only the DAS could do that, there could be ways in which that is
>>>>> relaxed
>>>>> going forward so non-DAS servers might be able deploy apps - although
>>>>> perhaps only to themselves rather than to the whole domain. So, in
>>>>> fact,
>>>>> perhaps some piece of code really needs to distinguish between
>>>>> "can deploy
>>>>> to domain" vs. "can deploy only to self."
>>>>>
>>>>> Ideally, we'd understand at each bit of code precisely what
>>>>> characteristic
>>>>> of DAS-ness or non-DAS-ness the code was really interested in and
>>>>> then
>>>>> expose that in some coherent way, whether it's on
>>>>> ServerEnvironment or in
>>>>> some other way.
>>>>>
>>>>> - Tim
>>>>>
>>>>> On Apr 21, 2011, at 3:09 PM, Hong Zhang wrote:
>>>>>
>>>>>> Hi, Tom
>>>>>> We have been using ServerEnvironment.isDas API, the underlying
>>>>>> implementation is checking the server type.
>>>>>>
>>>>>> - Hong
>>>>>>
>>>>>> On 4/21/2011 3:57 PM, Tom Mueller wrote:
>>>>>>> I've been looking into how a DAS determines that it's a DAS, and
>>>>>>> I'm
>>>>>>> seeing some different approaches:
>>>>>>>
>>>>>>> 1. Calling Server.isDas() - this method looks at the instance
>>>>>>> name; if
>>>>>>> it's "server" then return true.
>>>>>>>
>>>>>>> 2. Using the "-type" argument that is passed when the JVM is
>>>>>>> launched.
>>>>>>> start-domain passes in DAS, start-local-instance passes in
>>>>>>> INSTANCE.
>>>>>>>
>>>>>>> 3. Calling Server.getName() and doing the comparison to "server"
>>>>>>> directly,
>>>>>>> rather than calling isDas().
>>>>>>>
>>>>>>> Do you know of other ways that code determines whether it is
>>>>>>> running on
>>>>>>> the DAS?
>>>>>>>
>>>>>>> I'd like to move in the direction of consolidating this
>>>>>>> behavior, so that
>>>>>>> we have exactly one way of determining the role that the server is
>>>>>>> filling. Thoughts?
>>>>>>>
>>>>>>> Thanks.
>>>>>>> Tom
>>>>>>>
>>>>>
>>>
>