On Jun 3, 2009, at 10:59 PM, Mattias Jiderhamn wrote:
Scott Ferguson wrote (2009-06-03 23:52):
On Jun 3, 2009, at 1:08 PM, Mattias Jiderhamn wrote:
Scott Ferguson wrote (2009-06-03 21:17):
Can you check the permissions, particularly of the resin-data
directory? We had some trouble at the end of the release cycle
with permissions issues on the created directories, and it's
possible we didn't catch all of the cases.
I'm pretty sure it's not related to permissions. Running with full
permissions, tried deleting resin-data dir and it is recreated.
Should I send you the files in it???
Sure. The important ones should be resin_data_default.db and
resin_mnode_default.db.
Done a bit more debugging and I have arrived at
com.caucho.server.distcache.FileCacheManager.put() which does
nothing but return null!?
Should persistent-store type=file work at all...?
Yikes. All of our testing for sessions was against Resin Pro, which
uses the cluster version. I've refactored the code, and added open
source testing for the basic session behavior.
-- Scott
I've added a bug report for the junction issue. It's not
something I'm familiar with.
I don't think there is a junction issue. I've had this
configuration for a long time just changing the target of the
junction/symbolic link. But somehow the RESIN_HOME environment
variable takes precedence over the resin.exe location and that
affects sessions somehow.
Yes, that is exactly what is happening, so I was running 3.1.8 when
the sessions worked... *blush*
/Mattias
Scott Ferguson wrote (2009-06-02 23:50):
On Jun 2, 2009, at 12:29 PM, Mattias Jiderhamn wrote:
I wrote on resin.conf = null when upgrading to Resin
4 (2009-06-02
06:48):
Sitting here trying to upgrade the dev environment to Resin
4.0 with
minimal changes to configuration and startup scripts.
On Windows I'm up and running ...
I apparently jumped the gun here. I am not up and running on
Windows
either.
While picking up my resin.conf, Resin does not handle sessions
but
resets them on every request.
Example fine log, first request:
[20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new
[20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create
session
...
Subsequent request:
[20:57:27.250] Http[11] Cookie: JSESSIONID=aaaQKDKMBgGTm9hnkvIgs
[20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset
[20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset
[20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new
[20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create
session
The reset is normally a message that something went wrong in
loading
the session. I'll need to see if we can either improve the
information or just fix the issue.
The bug is at http://bugs.caucho.com/view.php?id=3545
Tried to find a configuration fault by debugging, but I end up
really
confused. When com.caucho.server.session.SessionImpl.save() is
entered,
I have a couple of values in the session, but when stepping
into the
isValid() the _values Map is suddenly empty???
Here is my session config:
persistent-store type=file
init
pathc:\temp\resin-sessions/path
always-savetrue/always-save
/init
/persistent-store
FYI, this is ignored, currently, because the persistent store is
always available (it lives in resin-data). You do still need
use-
persistent-store to enable the session to use it.
-- Scott
+
session-config
use-persistent-store /
session-max4096/session-max
session-timeout30/session-timeout
/session-config
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
