0003872: session data is replicated between cluster instances in resin-data dir when persistent sessions are disabled

Notes
(0004408) ferg 02-03-10 12:57	Do you have the <use-persistent-store/> in the session-config in a <web-app-default>? I just checked here and the default is off, but the sample resin.xml includes a <web-app-default> which enables the persistent sessions. The <persistent-store> itself doesn't really do anything currently. That top-level configuration is always enabled, because Resin shares information across the cluster outside of the session store. (But that data is very small, so shouldn't create a large *.db file.)

(0004409) chiefgeek 02-03-10 13:03	The docs say to put this in to enable it <use-persistent-store="true"/> That causes a parse error. Originally I had nothing and then I tried this with no change: <use-persistent-store>false</use-persistent-store>

(0004410) chiefgeek 02-03-10 13:30	I noticed the following in the log with debug=finer [10-02-03 16:16:36.791] {main} Database[null] active [10-02-03 16:16:36.798] {main} Database[/usr/local/resin/resin-data]: SELECT id, value, cache_id, flags, expire_timeout, idle_timeout, lease_timeout, local_read_timeout, update_time, server_version, item_version FROM resin_mnode_dealfinder WHERE 1=0 [10-02-03 16:16:36.873] {main} Database[/usr/local/resin/resin-data]: SELECT MAX(server_version) FROM resin_mnode_dealfinder [10-02-03 16:16:36.874] {main} Database[/usr/local/resin/resin-data]: SELECT MAX(update_time) FROM resin_mnode_dealfinder [10-02-03 16:16:36.875] {main} Database[/usr/local/resin/resin-data]: DELETE FROM resin_mnode_dealfinder WHERE update_time + 5 * idle_timeout / 4 < ? OR update_time + expire_timeout < ? [10-02-03 16:16:36.882] {main} Database[/usr/local/resin/resin-data]: SELECT id, expire_time, data FROM resin_data_dealfinder WHERE 1=0 [10-02-03 16:16:36.885] {main} Database[null] active [10-02-03 16:16:36.885] {resin-39} Database[/usr/local/resin/resin-data]: VALIDATE resin_data_dealfinder [10-02-03 16:16:36.886] {resin-39} Database[/usr/local/resin/resin-data]: SELECT value, resin_oid FROM resin_mnode_dealfinder WHERE resin_oid > ? [10-02-03 16:16:36.886] {resin-39} Database[/usr/local/resin/resin-data]: UPDATE resin_data_dealfinder SET expire_time=? WHERE id=? [10-02-03 16:16:36.887] {resin-39} Database[/usr/local/resin/resin-data]: DELETE FROM resin_data_dealfinder WHERE expire_time < ? and here is a ls -l from a production server -rw-rw-r-- 1 root root 192K 2010-02-02 08:58 resin_data_flights.db -rw-rw-r-- 1 root root 192K 2010-01-29 18:41 resin_data_json.db -rw-rw-r-- 1 root root 123M 2010-02-03 16:27 resin_mnode_flights.db -rw-rw-r-- 1 root root 115M 2010-02-03 16:27 resin_mnode_json.db -rw-rw-r-- 1 root root 128K 2010-02-02 08:58 temp_file_flights -rw-rw-r-- 1 root root 128K 2010-01-29 18:41 temp_file_json

(0004411) ferg 02-03-10 13:43	That log is normal, because the store needs to GC/delete expired entries periodically. However, the size of the mnode files is strange since you're not using the persistent store. The data files are about what I'd expect, but the mnodes should be about the same size (about 1M or less.) That helps a bit.

(0004432) ferg 02-17-10 14:04	server/01o4

Issue History
Date Modified	Username	Field	Change
02-03-10 11:42	chiefgeek	New Issue
02-03-10 12:57	ferg	Note Added: 0004408
02-03-10 13:03	chiefgeek	Note Added: 0004409
02-03-10 13:30	chiefgeek	Note Added: 0004410
02-03-10 13:43	ferg	Note Added: 0004411
02-17-10 14:04	ferg	Note Added: 0004432
02-17-10 14:04	ferg	Assigned To	=> ferg
02-17-10 14:04	ferg	Status	new => closed
02-17-10 14:04	ferg	Resolution	open => fixed
02-17-10 14:04	ferg	Fixed in Version	=> 4.0.4

Relationships