Ø  "For example, if users have a floating license, they can potentially 
allocated a floating license on each server that their request is sent to."


Just to clarify, one user takes one floating token within a server group - even 
if there are individual requests from the same user to each server in a server 
group.  So no matter how many different servers in a server group that user 
accesses, they'll get one token.

There is logic in the system that stores logged in users in a table that the 
various servers can coordinate from.  Thus, I do not believe that scenario can 
actually happen.

Maybe I'm misunderstanding the scenario...

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.

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.

From: Action Request System discussion list(ARSList) 
[mailto:[email protected]] On Behalf Of Axton
Sent: Friday, January 14, 2011 11:04 AM
To: [email protected]
Subject: Re: Server Group node

** 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]<mailto:[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]<mailto:[email protected]>] On Behalf Of LJ 
LongWing
Sent: 14 January 2011 17:52

To: [email protected]<mailto:[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 :)

From: Action Request System discussion list(ARSList) 
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Axton
Sent: Friday, January 14, 2011 10:11 AM
To: [email protected]<mailto:[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<http://www.wwrug.com> ARSlist: "Where the Answers 
Are"_
_attend WWRUG11 www.wwrug.com<http://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"

Reply via email to