Only 2 groups of people that I can think of that won't care about the floating license multiple allocations: - people that don't use floating licenses - people that don't use (or pay for) floating licenses
Chances are that applies to a very small subset of users, if any. 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 12:00 PM, Danny Kellett < [email protected]> wrote: > ** > > I guess its not true load balancing then. Just load sharing. If you have a > session infinity set at the LB on in front of the ARServers then there is no > difference that having each midtier bypassing the LB and going straight to > the ARServer instance. E.g. mt1 to AR1, mt2 to AR2 etc > > > > I don’t think anyone would want to implement something that could take more > than one floating license at one time though Axton right? > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *LJ LongWing > *Sent:* 14 January 2011 17:52 > > *To:* [email protected] > *Subject:* Re: Server Group node > > > > ** > > From Page 8 of 84092-Using A Hardware Load Balancer with AR System.pdf > > > > The load balancer acts like a NAT device that routes any TCP or UDP > traffic. Since the AR System server uses an ONC-RPC implementation that is > layered on top of TCP/IP, AR System server traffic can be load balanced. > Because of the nature of the client/server interaction within AR System, the > "sticky" option is required. This reduces the balancing that can occur, but > still allows for the spreading of the workload from multiple clients. > > > > I’m just using the docs J > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* Friday, January 14, 2011 10:11 AM > *To:* [email protected] > *Subject:* Re: Server Group node > > > > ** 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. > > _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"
