On Thu, Mar 29, 2012 at 10:31 AM, Tom Evans <tevans.uk@xxxxxxxxxxxxxx> wrote: > On Thu, Mar 29, 2012 at 5:14 PM, Ryan Bowman <ryanlbowman@xxxxxxxxx> wrote: >> That doesn't sound correct to me, the balancer-manager page has a >> status column, and shows that one is OK, the other is Err. (see the >> attached screen shot) >> >> Apache knows that the backend server is having problems, shouldn't >> Apache then know to send the requests to healthy nodes? >> > > There are no healthy nodes for that route, You seem to be implying that a given route can have multiple nodes? As in there can be two jboss servers with the same jvmRoute? Then how does Apache distinguish the two servers for the purposes of sticky sessions? That doesn't sound right to me. > and no redirect route configured for that route. Perhaps I am misunderstanding the purpose of the redirect rule. the doc says **** This value is usually set dynamically to enable safe removal of the node from the cluster. If set all requests without session id will be redirected to the BalancerMember that has route parameter equal as this value. **** which implies to me that requests WITH session id and that route specified will still be sent to that node, which then yields the exact same behavior I'm getting now. Requests without the route in the session id will go to node 1, but since node 2 is down, Apache is already sending new requests to node 1. what I need is for requests destined for route 2 to fail over to a different route, because route 2 is broken. > Also, you have "nofailover=off", but say "what I want is that if the > node is down that all requests would go > to the up node, sticky sessions be damned". Surely you just want this option on? > > """ > nofailover - Off - If set to On the session will break if the worker > is in error state or disabled. Set this value to On if backend servers > do not support session replication. > """ I get the same behavior no matter what if nofailover is set to On or Off. > > If you have session replication, then both backends should be on the same route. Clearly, that is the optimal solution, but we do not have the time to work on that particular puzzle right now. > > Cheers > > Tom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|