How to disable default session replication in WildFly

[valsaraj007]

When we use thrid party in-memory data grid tools for web application session replication, how can we disable default replication settings in WildFly full-ha profile?

[jaysensharma]

For whatever application you do not want the session replication you can simply do one thing ...  Do not put <distributable/> tag in your web.xml of that web application.

[jaysensharma]

At the profile level if you want to do it then try the following:

Try changing the "cache-container"  web  setting in infinispan subsystem and change it from "distributed-cache" to "local-cache" as following:

ORIGINAL

            <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
                <transport lock-timeout="60000"/>
                <distributed-cache name="dist" mode="ASYNC" batching="true" l1-lifespan="0" owners="2">
                    <file-store/>
                </distributed-cache>
            </cache-container>

CHANGED

            <cache-container name="web" default-cache="passivation" module="org.wildfly.clustering.web.infinispan">
                <local-cache name="passivation" batching="true">
                    <file-store passivation="true" purge="false"/>
                </local-cache>
                <local-cache name="persistent" batching="true">
                    <file-store passivation="false" purge="false"/>
                </local-cache>
            </cache-container>

[valsaraj007]

I want web application to be distributable but need to disable wildfly built in replication as I am using third party tool for this. What is the impact when change it from "distributed-cache" to "local-cache"?

[jaysensharma]

You said that you are using some third party tool for replication.    Can you please let us know more about what that third party tool is ? So that we can check how it does the replication and Why that third party tool needs <distributable/> tag in web.xml ?

[ctomc]

valsaraj viswanathan wrote:

I want web application to be distributable but need to disable wildfly built in replication as I am using third party tool for this. What is the impact when change it from "distributed-cache" to "local-cache"?

Than you don't run clustered configuration (the -ha- ones)

or just plainly remove <distributable /> from your web.xml

[valsaraj007]

Hi Jay,

Please go through this: https://hazelcast.com/use-cases/web-session-clustering/generic-web-session-replication/

We are going to replace the built in wildfly replication with this. So I want to know what all we need to disable in wildfly or just remove distributable.

[jaysensharma]

Valsaraj, thank you for sharing more information about the framework which you are using for distributed sessions.

In that case as "Tomaz Cerar" said  if you really do not want to use WildFly ha features then don't run clustered configuration (the -ha- ones). You can use standalone-full.xml/standalone.xml)  rather than   standalone-full-ha.xml

[valsaraj007]

So full-ha only does session replication in addition to full? Or I just remove <distributable /> from web descriptor?

[pferraro]

Let me clarify some semantic confusion:

Using <distributable/> in your web.xml simply tells WildFly to use an Infinispan-backed session manager.  The capabilities of that session manager are determined by the Infinispan cache configuration.  In our out-of-the-box configuration profiles, ha and full-ha will use a distributed cache, whereas the default profile and full profiles will use a local passivating cache configuration.  Both configurations require serializable session attributes.

You should also be aware that you *must* use <distributable/> to prevent false session destroyed events from getting triggered on undeploy or shutdown of a node.

I would also caution you to be aware that such a setup (as described in Generic Web Session Replication - Hazelcast.com) will not behave in an entirely spec-compliant way.  In particular:

• If your load balancer does not consistently direct requests for a given session to the same node, a session can expire prematurely.
• A given session can be accessed by multiple nodes concurrently (See 7.7.2)
• Activation/passivation callbacks will not be triggered correctly
• Session destroyed callbacks can occur on multiple nodes
• Session destroyed callbacks may never be triggered if a session times out following failover
• Any access to the session from outside the scope of the hazelcast servlet filter (i.e. by WildFly internals) are subject to stale session reads

There very well may be others, but I would need to look at the implementation in more detail.

[valsaraj007]

Thank you Paul!

It's clear now. Is there any steps that we can follow to replace infinispan cache with any other in-memory cache like this?

[skac1910]

Hi, quick question I am curious what is the third party tool are you using for session management? thanks!