Hello Cathy,

thanks for your advice. But the customer doesn't use a backup rserver or a backup serverfarm. He wants to use remaining rservers in the serverfarm:

serverfarm TEST

rserver s1

ins

rserver s2

ins

rserver s3

ins

... - so when the server s1 will fail, the connection for the same user (with cookie for rserver s1) would be load-balanced between remaining servers (s2 and s3). I think that ACE makes it, because I see failed connection for these rservers in the show serverfarm TEST, but the customer doesn't have any output in the browser.

Roman

Hi Roman,

You don't need a backup server or serverfarm to use the "failaction purge" command.  Users on the failed rserver will have their session terminated and they'll have to restart their connect. This will then bind to one of the remaining active servers. There isn't an easy way to transparently transfer the session. The point of stickiness is that it is used in a situation where the client and the server maintain a state (e.g. the user's authentication), so unless this state information is replicated between the servers "behind the scenes" it doesn't make a lot of sense to fail the session to another rserver.

HTH

Cathy

Hi Cathy,

I tried to use commands failaction purge and failaction reassign, but the behaviour is same:-( See:

sho serverfarm TEST
serverfarm     : TEST, type: HOST
total rservers : 6
---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total      failures
   ---+---------------------+------+------------+----------+----------+---------
   rserver: s1
       10.254.254.18:0       8      OPERATIONAL  0          1878       68
   rserver: s2
       10.254.254.24:0       8      OUTOFSERVICE 0          409        1

The rserver s2 - it is the server where the client sent first request, for now it is out of service and the failures are increasing for rserver s1.:-(

sho serverfarm TEST detail
serverfarm     : TEST, type: HOST
total rservers : 6
active rservers: 1
description    : -
state          : ACTIVE
predictor      : LEASTCONNS
   slowstart    : 0 secs
failaction     : PURGE
back-inservice    : 0
partial-threshold : 0
num times failover       : 0
num times back inservice : 0
total conn-dropcount : 0
Probe(s) :
    HTTP,  type = HTTP
    HTTP_443,  type = HTTP

---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total      failures
   ---+---------------------+------+------------+----------+----------+---------
   rserver: s1
       10.254.254.18:0       8      OPERATIONAL  0          1880       68
         max-conns            : -         , out-of-rotation count : -
         min-conns            : -
         conn-rate-limit      : -         , out-of-rotation count : -
         bandwidth-rate-limit : -         , out-of-rotation count : -
         retcode out-of-rotation count : -

   rserver: s2
       10.254.254.24:0       8      OUTOFSERVICE 0          409        1
         max-conns            : -         , out-of-rotation count : -
         min-conns            : -
         conn-rate-limit      : -         , out-of-rotation count : -
         bandwidth-rate-limit : -         , out-of-rotation count : -
         retcode out-of-rotation count : -