Distributed cache for web cache container

[t3rm1]

I become really desperate with this ^^ It just doesn't work. The seesion is always replicated to all nodes and I don't know why.

1 group with full-ha profile (domain mode)

4 server in that group including the master

The default-cache is set to dist for the web cache container. Owners is set to 1 (2 doesn't work either). Configuration below. (yes, this is under the full-ha profile)

<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="cluster">
                <cache-container name="cluster" aliases="ha-partition" default-cache="default">
                    <transport lock-timeout="60000"/>
                    <replicated-cache name="default" mode="SYNC" batching="true">
                        <locking isolation="REPEATABLE_READ"/>
                    </replicated-cache>
                </cache-container>
                <cache-container name="web" aliases="standard-session-cache" default-cache="dist">
                    <transport lock-timeout="60000"/>
                    <replicated-cache name="repl" mode="ASYNC" batching="true">
                        <file-store/>
                    </replicated-cache>
                    <replicated-cache name="sso" mode="SYNC" batching="true"/>
                    <distributed-cache name="dist" owners="1" mode="ASYNC" batching="true">
                        <file-store/>
                    </distributed-cache>
                </cache-container>
                <cache-container name="ejb" aliases="sfsb sfsb-cache" default-cache="repl">
                    <transport lock-timeout="60000"/>
                    <replicated-cache name="repl" mode="ASYNC" batching="true">
                        <eviction strategy="LRU"/>
                        <file-store/>
                    </replicated-cache>
                    <replicated-cache name="remote-connector-client-mappings" mode="SYNC" batching="true"/>
                    <distributed-cache name="dist" mode="ASYNC" batching="true">
                        <eviction strategy="LRU"/>
                        <file-store/>
                    </distributed-cache>
                </cache-container>
                <cache-container name="hibernate" default-cache="local-query">
                    <transport lock-timeout="60000"/>
                    <local-cache name="local-query">
                        <transaction mode="NONE"/>
                        <eviction strategy="LRU" max-entries="10000"/>
                        <expiration max-idle="100000"/>
                    </local-cache>
                    <invalidation-cache name="entity" mode="SYNC">
                        <transaction mode="NON_XA"/>
                        <eviction strategy="LRU" max-entries="10000"/>
                        <expiration max-idle="100000"/>
                    </invalidation-cache>
                    <replicated-cache name="timestamps" mode="ASYNC">
                        <transaction mode="NONE"/>
                        <eviction strategy="NONE"/>
                    </replicated-cache>
                </cache-container>
            </subsystem>

I have a jsp which prints the session id. I visit the page on the first server and see the id. The id is the same on every other server regardless in which order I visit them. Why does this happen? I exptect the session to be only replicated to one server, not to all.

Any ideas? :/

[pferraro]

When using DIST mode, the session will only be stored on X nodes in the cluster, where X is determined by the owners attribute.  However, *any* node can query the cache and retrieve the session.  In the case where this query is performed on a node that is *not* an owner, an RPC is made to retrieve the value from one of the owners.  Hence, when you visit any server in your cluster, a given session is always accessible.

[t3rm1]

H Oh, good to know. That explains a lot.

However I was once able to have the sessions only replicated to the number of nodes specified in owners. All other nodes didn't have the session and created a new one. Too bad I'm not able to reproduce this any more so I trust your answer now