Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1367651 - [GSS](6.4.z) HTTP sessions are not passivated to files only on the coordinator
Summary: [GSS](6.4.z) HTTP sessions are not passivated to files only on the coordinator
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Clustering
Version: 6.4.9
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: jboss-set
QA Contact: Michal Vinkler
Depends On:
Blocks: 1496501
TreeView+ depends on / blocked
Reported: 2016-08-17 06:23 UTC by Osamu Nagano
Modified: 2019-03-08 15:00 UTC (History)
6 users (show)

Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)
httpsession_sample.war (deleted)
2016-08-17 06:23 UTC, Osamu Nagano
no flags Details

Description Osamu Nagano 2016-08-17 06:23:36 UTC
Created attachment 1191470 [details]

Description of problem:
A web application has the following configuration in its jboss-web.xml.


Then a session will be passivated very soon in a file in ${}/infinispan/web/default-host/<WEBAPP>/ except the coordinator. But when you shutdown the coordinator, sessions will have been passivated at that time.

How reproducible:

Steps to Reproduce:
1. Deploy attached httpsession_sample.war to a cluster.
2. Create some sessions.
curl -v "http://localhost:8380/httpsession_sample/index.jsp"
3. Watch the file store directories.
ls $JBOSS_HOME/domain/servers/*/data/infinispan/web/default-host/httpsession_sample/

Actual results:
Files are created in the directory except the coordinator.

Expected results:
Files are created for all nodes including the coordinator because the cache is a replication cache.

Comment 12 Paul Ferraro 2017-10-04 14:03:49 UTC
The exception in comment #9 should be resolved by  Failure to acquire a lock during passivation is not unexpected - it means that a request is currently using the session, which is why the FAIL_SILENTLY flag should be used.  Additionally, the CACHE_MODE_LOCAL flag should also be used when acquiring the lock on the session during passivation to ensure that multiple nodes can concurrently passivate the same session.

The reproducer configuration in the description is not ideal, since this means that the passivation task might try to passivate a session before the current request completes.  I suggest using a longer passivation-min-idle time when attempting to reproduce the issue.

Additionally, the customer may still have memory issues even after this passivation fix is committed, since a design flaw in EAP6 permits a session to be referenced in the distributed cache, but not in the session manager.  This is the case when a session replicates to other nodes where it has not be explicitly referenced by any request.  Enabling eviction in the Infinispan cache configuration is the only real workaround for this.

Note You need to log in before you can comment on or make changes to this bug.