Authentication information is included in each packet to the arserver, so it can run without session persistence. However, there are trade-offs. For example, if users have a floating license, they can potentially allocated a floating license on each server that their request is sent to. This statement does not apply to the mid-tier layer though. The J2EE container in use has session information stored that is required to handle requests from a user. If the user is re-directed to a mid-tier server where this session information is not available, the user will fail authentication and will be redirected to the login interface.
The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. On Fri, Jan 14, 2011 at 10:09 AM, LJ LongWing <[email protected]> wrote: > ** > > Danny, > > According to the documentation, you MUST have session affinity turned > on….so it only benefits you to have a server group if you have more than one > mid tier node….only benefits the user traffic through that mid tier node at > least, the other node can still perform admin operations and such…in > addition to being available to other clients. > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Danny Kellett > *Sent:* Friday, January 14, 2011 8:32 AM > > *To:* [email protected] > *Subject:* Re: Server Group node > > > > ** > > I actually think its worth having some very small text on the home page > that tells the user which node they are on. > > > > I guess the only thing to remember is that if you don’t have the sticky bit > set (Session infinity as its sometimes known) then you could get directed to > others depending on the LB config. > > > > Actually thinking about this, I guess you can not have the sticky bit on > the LB in front of the AR Servers as this would mean that all your midtier > traffic would only go through one server.... > > > > Food for thought anyway.... > > Regards > > Danny > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *LJ LongWing > *Sent:* 14 January 2011 15:28 > > *To:* [email protected] > *Subject:* Re: Server Group node > > > > ** > > J > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Danny Kellett > *Sent:* Friday, January 14, 2011 8:01 AM > *To:* [email protected] > *Subject:* Re: Server Group node > > > > ** > > You can do a set fields from “Configuration ARDBC” and the query is > something like ‘Name’ = “Server-Connect-Name” > > > > Kind regards > > Danny > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *LJ LongWing > *Sent:* 14 January 2011 14:56 > *To:* [email protected] > *Subject:* Re: Server Group node > > > > ** > > J….I figured yesterday that I would use a perl script to pull the > ‘Server-Connection-Name’ out of the ar.cfg file….what I was hoping for > honestly was a keyword like $SERVER-NODE$ or something ‘stupid easy’ like > that…J > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* Thursday, January 13, 2011 5:27 PM > *To:* [email protected] > *Subject:* Re: Server Group node > > > > ** Logs, tcpdump, netstat, and many more utilities can be used to > determine this. It's a PITA at times, but doable. Beyond that you can test > the nodes individually by connecting to them individually to > troubleshoot/diagnose problems. > > On Thu, Jan 13, 2011 at 4:09 PM, LJ LongWing <[email protected]> > wrote: > > ** > > Well, as we are setting up and configuring the nodes, there is always the > possibility that a user may be having trouble, trouble that’s specific to a > certain node of the group (environment related)…and without the ability for > us to know what app node a user is on, it makes it difficult to know which > of the app nodes is causing the problem. In production we have the > following architecture > > > > Load Balancer > > 4 Mid-Tier > > Load Balancer > > 2 App > > > > So, any one of the 4 web nodes could be pointing to any one of the app > nodes….so it would be nice to be able to pinpoint which node, both web and > app a user is using. J > > > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* Thursday, January 13, 2011 2:15 PM > *To:* [email protected] > *Subject:* Re: Server Group node > > > > ** Want to share more around what you are trying to accomplish? Why do you > need to know the name? > > On Thu, Jan 13, 2011 at 2:32 PM, LJ LongWing <[email protected]> > wrote: > > ** > > I’m setting up server groups. I have the need to know which node I’m > currently on when connected through the load balanced name. According to > the 7.5 docs…all nodes should have the same ‘Server-Name’, but each node > registers with the group with the ‘Server-Connect-Name’. it is the connect > name I want to be able to access through workflow. Any/all suggestions are > appreciated. > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
