2 sessions created in tomcat while using java_servlet_store

Hi,

We have a jruby on rails application deployed in tomcat.
The session store that we use is :
java_servlet_store

A snippet of our session store file is:

#ActionController::Base.session = {

:key => ‘----’,

:secret => ‘-------’,

#}

Use the database for sessions instead of the cookie-based default,

which shouldn’t be used to store highly confidential information

(create the session table with “rake db:sessions:create”)

ActionController::Base.session_store = :active_record_store

#This is commented because in tomcat we were facing abrupt session
timeouts
ActionController::Base.session_store = :java_servlet_store if
defined?($servlet_context)

What we noticed is that on tomcat 2 sessions are created consistently
for each login.

And each of the session have an attribute value of
current_rails_session.

And the second session which is created, if we kill it explicitly still
everything works fine because of the first session_id.
Another way we used to verify is that, we displayed the session id to
see which one is used, its the first one created which is used.

Is this a known issue?

Environment:
Jruby version is 1.5.2
Tomcat version: 6.0.26
Rails version : 2.3.5

On Dec 2, 2010, at 01:55 , Prachi T. wrote:

:secret => ‘-------’,

ActionController::Base.session_store = :java_servlet_store if
Another way we used to verify is that, we displayed the session id to
see which one is used, its the first one created which is used.

Is this a known issue?

Environment:
Jruby version is 1.5.2
Tomcat version: 6.0.26
Rails version : 2.3.5

I haven’t heard about this before. Can you file a bug in
http://kenai.com/jira/browse/JRUBY_RACK or http://bugs.jruby.org? It
would help greatly if you can outline how to reproduce this problem.

/Nick

HI Nick,

We found out that the error was not in jruby, It was caused because
apache created an internal dummy connection :
::1 - - ***************** (internal dummy connection)"

Due to this an extra session was getting created when number of parallel
requests increased.

Hope this input helps if someone else faces this issue.

Thanks.