the
load-balancer, and only then replicating, exposes me to the chance that a
request will come in to Node Y, which is the backup-to-be of the session,
while the session is not yet fully replicated. Again, does tribes handle
that?
Naaman
--
View this message in context:
http://www
Ok, the backup manager which does two things
1. [every request] it selects a backup node and each time the session
changes it publishes the delta to the back up node
2. [one time] upon session creation it also notifies the other nodes
with the location of the backup node for session X
should
plicate.
> And then simply implement a "move sessions" during a graceful shutdown.
>
> Filip
>> I would appreciate any tips.
>>
>> Thanks,
>> Naaman
>>
>
>
> -----
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additiona
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
--
View this message in context:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nilf,
nlif wrote:
> We intend to run in a cluster, with stickiness enabled, and without
> replication. This of course does not give us failover capabilities, in case
> of a server crash, but it is sufficient for our needs.
>
> However, we would like
nlif wrote:
Hi all,
We intend to run in a cluster, with stickiness enabled, and without
replication. This of course does not give us failover capabilities, in case
of a server crash, but it is sufficient for our needs.
However, we would like to be able to transfer all sessions currently on on
thing?
I would appreciate any tips.
Thanks,
Naaman
--
View this message in context:
http://www.nabble.com/Transfer-all-HttpSessions-from-one-cluster-node-to-another-tp21649886p21649886.html
Sent from the Tomcat - User mailing list archive at Nabble.com
