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