dev@glassfish.java.net

Re: Review of http-lb commands and some other questions....

From: Carla Mott <Carla.Mott_at_Sun.COM>
Date: Fri, 25 Aug 2006 16:21:24 -0700

vince kraemer wrote:

> Good.
>
>>> As an aside: Why aren't we filing this in issue tracker?
>>
>>
>>
>> In the issue tracker I only saw "9.0pe, 9.0peur1, 9.1pe". I was
>> looking for a EE category. Now that EE features are exposed in
>> GlassFish, which is the right version to choose? I will dig up my
>> previous emails to see if I missed any existing conversations on this
>> topic. I thought all the bugs are available to view issue tracker
>> soon and 2 way bridge will be operational soon. I will file the next
>> bug using issue tracker, so that we do not have wait for 2 way bridge.
>
>
> Carla?

If this can wait til monday I can talk at pteam about this. If we are
going to have
one release then we don't need a 9.1pe and 9.1ee...

>>
>> [snip]
>>
>>> What are the semantics of --lbenableallinstances?
>>>
>> enableallinstances only valid for enabling during creation. by
>> default they are disabled. enableallinstances works for only one
>> target, as you can add one target at a time to lbconfig. there is no
>> create-http-lb-ref --target c1, c2, c3
>>
>> create-http-lb-config c1-lb-config
>> create-http-lb-ref --config c1-lb-config c1
>>
>> (in memory object)equivalent to the following:
>>
>> <loadbalancer>
>> <cluster name="c1">
>> <instance disable-timeout-in-minutes="30" enabled="false"
>> listeners="http://
>> chandu.sfbay:8080 https://chandu:8181 https://chandu:4849"
>> name="server"/>
>> <web-module context-root="/jaxrpc-simple"
>> disable-timeout-in-minutes="30" en
>> abled="false"/>
>> </cluster>
>> ....
>>
>> however
>>
>> create-http-lb-config c1-lb-config
>> create-http-lb-ref --lbEnableAllInstances --lbEnableAllApplications
>> --config c1-lb-config c1
>>
>> <loadbalancer>
>> <cluster name="c1">
>> <instance disable-timeout-in-minutes="30" enabled="true"
>> listeners="http://
>> chandu.sfbay:8080 https://chandu:8181 https://chandu:4849"
>> name="server"/>
>> <web-module context-root="/jaxrpc-simple"
>> disable-timeout-in-minutes="30" en
>> abled="true"/>
>> </cluster>
>> ....
>
>
> Why do we assume that people would want to create a disabled
> http-lb-ref? It seems like folks would want it to be enabled by default?
>
> Another way to ask that q, might be, "Why would a person
> create-http-lb-ref and leave it disabled?"
>
>>
>>
>>>>
>>>>>
>>>>> [snip]
>>>>>
>>>>> Is the default disable-timeout-in-minutes really 31 or is it
>>>>> "session idle timeout"+1?
>>>>
>>>>
>>>>
>>>> Default is 31. disable-timeout-in-minutes CDATA "31"
>>>
>>>
>>>
>>> What will happen if the user changes the "session idle timeout" to
>>> be a value like 60, after they have created their lbxml and used it
>>> to configure their LB?
>>
>>
>>
>> This change will appear in lbxml, if they re-export again.
>
>
> Is there any interaction between the value of
> "disable-timeout-in-seconds" in the lbxml and the session-timeout
> element of a load balanced web app?
>
> Say I have a shopping cart that has a 60 minute session-timeout,
> deployed to an instance that is sitting behind an LB with a 31
> disable-timeout-in-minutes...
>
> Will the app behave the way I expect?
>
>>
>>>>
>>>>>
>>>>> Is the user required to execute disable-http-lb-server before
>>>>> they can execute delete-http-lb-ref? The document strongly
>>>>> implies that the user must do one then the other? Why is that?
>>>>> Why can't we give the user a SINGLE command to delete the ref?
>>>>> [That command may perform a disable "under the covers"]
>>>>>
>>>>> http://docs.sun.com/app/docs/doc/819-2555/6n4r9qo8h?a=view#abdhv
>>>>
>>>>
>>>>
>> As of now yes. please see my answers above. will look into this.
>>
>>>> We prefer do it explicitly on command and not to do "under the
>>>> covers".
>>>
>>>
>>>
>>> Why should we want to force the user to enter two commands instead
>>> of one???
>>
>>
>> User has both the choices
>>
>> 1). use one command configure-http-lb-config
>> 2). or multiple commands create-http-lb-config, create-http-lb-ref etc.
>
>
> Huh... I thought we were talking about disable and delete....
>
>>
>>>
>>> I realize there are cases, like rolling upgrades, where the user
>>> needs to do an explicit disable....
>>>
>> yes.
>>
>>> That implies that we must have a disable command... But it doesn't
>>> imply that a user must disable, before they delete...
>>>
>> I will check with Prashant to see if we can provide this.
>
>
> Good.
>
>>
>>>> Unless we hear lot of complaints from users that do it "under the
>>>> covers".
>>>>
>>>>>
>>>>> Is there a way to enable all the servers in a config with just one
>>>>> command? Something like:
>>>>>
>>>>> asadmin enable-http-lb-servers <config object name>
>>>>>
>>>>> or
>>>>>
>>>>> asadmin enable-http-lb-server -config <config object name>
>>>>>
>>>> Yes, during asadmin create-http-lb-ref --lbenableallinstances
>>>> --config config_name target and asadmin create-http-lb-ref.
>>>
>>>
>>>
>>> I am lost here...
>>>
>>> Say I have an http-lb-config (Z) with 3 instances or clusters (a, b,
>>> c) already created...
>>>
>>> How would I use create-http-lb-ref to enable them all at one time?
>>> Is there an example someplace?
>>
>>
>>
>> I guess it will be more clear, when documentation for all these new
>> options is available. Right now there is no 9.0 EE documentation for
>> LB admin. I have only CLI commands.
>>
>> Simple answer to question is that no we do not support dealing with
>> multiple cluster at once at this point. one cluster at a time.
>
>
> I think this design choice needs to be re-examined.
>
>>
>>>
>>>>
>>>>> It seems like the only way to do this today is to enter an
>>>>> enable-http-lb-server command for each server or cluster that may
>>>>> be in the config... That seems like it would be error prone...
>>>>> (people forgetting to enable an instance or cluster)...
>>>>>
>>>>> The same comment would apply to disable.
>>>>>
>>>>> http://docs.sun.com/app/docs/doc/819-2555/6n4r9qo8h?a=view#abdhw
>>>>
>>>>
>>
>> Better to make people enable the instances, rather than exposing any
>> un-intended applications to LB by default. Since we automatically add
>> applications to LB. The least can do is enable them. Please see my
>> below comments.
>>
>>>>>
>>>>> I have a similar question/suggestion for applications as the one I
>>>>> just made for servers...
>>>>>
>>>>> It looks like enable-http-lb-application implies a
>>>>> create-http-lb-application operation (adds a web-module entry into
>>>>> the http-lb-config...). How do I delete a web-module entry from
>>>>> an http-lb-config? Is there a remove-http-lb-application command
>>>>> that I missed?
>>>>
>>>>
>>
>> Sorry. I missed these questions.
>>
>> There is no such thing. User does not have to enlist the
>> applications in the load balancers. Once user adds a cluster to LB,
>> LB admin code figures out which applications are deployed on that
>> cluster and adds those to LB. Similarly once an application
>> un-deployed from a cluster, it is also removed from those load
>> balancers.
>
>
> Okay... so deploying/undeploying applications will modify the
> http-lb-config...
>
> Is there some code int the undeploy command to stop someone from
> undeploying a deployed lb'ed app? Or is that unneeded?
>
>>
>>>>>
>>>>> What command is used to set/change the attributes of a web-module
>>>>> element?
>>>>>
>> This will be clear, once we talk about which element maps which
>> commands or where that information is obtained from. For example:
>>
>> <!ELEMENT web-module (idempotent-url-pattern*)>
>> <!ATTLIST web-module context-root CDATA #REQUIRED -->
>> comes from domain.xml ( context-root in web-module element for stand
>> alone modules, for an application it comes from descriptor)
>> enabled %boolean;
>> "true" --> asadmin
>> http-lb-enable-application
>> disable-timeout-in-minutes CDATA
>> "31" --> asadmin http-disable-http-application
>> --timeout (you can only modify during disable, because that is when
>> this is useful)
>> error-url CDATA "" >
>> --> existing bug to fix this
>
>
> okay.
>
>>
>>> [snip]
>>>
>>>>
>>>>
>>>> These 2 properties are global to loadbalancer, not specific to a
>>>> particular health-checker.
>>>
>>>
>>>
>>> Which is why they are documented in the section discussing the
>>> health-checker element?
>>>
>> Added to doc-improvement bug.
>>
>> Thanks again for all the input.
>>
>> We pushed in the past to do doc campaign to collect use cases and
>> review from the users/community. It would be nice if our external
>> users review these and give us comments. That would also dramatically
>> improve our document and make them very user friendly.
>
>
> Totally,
>
> vbk