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
>>>>>
>>>
>