-
1. Re: Http Session Replication using Remote Store not propagating updates to the clients
pferraro Dec 7, 2018 9:06 AM (in response to akrepon)Can you post your web cache-container configuration from the Infinispan subsystem?
-
2. Re: Http Session Replication using Remote Store not propagating updates to the clients
akrepon Dec 7, 2018 9:30 AM (in response to pferraro)Hi Paul,
This is my current configuration:
<cache-container name="web" default-cache="repl" module="org.wildfly.clustering.web.infinispan">
<transport lock-timeout="60000" />
<replicated-cache name="repl">
<transaction mode="BATCH" />
<remote-store cache="cms-http-session" remote-servers="remote-store-hotrod-server" passivation="false" />
</replicated-cache>
</cache-container>
I know that the sessions are replicated by clustering the wildfly nodes using the replicated-cache in this case. And the remote store serves as a backup store.
The remote store's main purpose is here have cross-site replication so that the changes on one site are propagated to the other site using jgroups relay.
But as I told you before the problem is that this setup is active/passive setup where the other site serves as a fail-over site. What we really want is to have a active/active setup where the state of the sessions is aligned at all times. This way we can avoid using sticky sessions.
After looking in the code a bit it seems the updates on the remote store are never propagated back to the wildfly nodes. There are no HotRod ClientListeners at all.
My question is, am I correct in my findings? If not, how can I achieve this active/active setup? Or if the ClientListeners are indeed missing in org.wildfly.clustering.web.infinispan module, is there any plan to implement this feature in the future?
Thanks in advance,
Yasin
-
3. Re: Http Session Replication using Remote Store not propagating updates to the clients
pferraro Dec 7, 2018 10:16 AM (in response to akrepon)For starters, your remote-store should be configured as a shared store, i.e. <remote-store shared="true"/>
Typically, one would only use a shared store (e.g. a remote-store) with an invalidation-cache. This means that session data is only cached locally and locally cached entries on other nodes are invalidated any time the state is updated.
However, this is not capable of invalidating state across sites. For that, you'll likely want to leverage the remote-cache based session manager, once it is merged: WFLY-7719 HotRod-based distributed session manager by pferraro · Pull Request #11662 · wildfly/wildfly · GitHub