wang-haha / memcached-session-manager

Automatically exported from code.google.com/p/memcached-session-manager
0 stars 0 forks source link

multiple parallel requests for the same session with msm has problem #151

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
  I use tomcat7, my config is:
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" 
memcachedNodes="n1:localhost:11211" 
requestUriIgnorePattern=".*\.(png|gif|jpg|css|js)$" 
sticky="false"
lockingMode="auto"
sessionBackupTimeout="10000"
operationTimeout="10000"
customConverter="com.zte.mobile.serializer.CustomKryoRegistration"
sessionBackupAsync= "false"
copyCollectionsForSerialization="false" 
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFact
ory" />
msm version is:
memcached-session-manager-1.6.2.jar
memcached-session-manager-tc7-1.6.2.jar
spymemcached-2.8.4.jar

   my application has many ajax requests when login is sucessed; when two requests use msm at the same time,  one request of them  save session using session.setAttibute do not work, the attibute do not save to mamcached.
  from the log ,I find first request load session from the memcached, second request do not load session, because the session has load by first request. but second request has not end, first request save session to memcached. I think first request do not save, second request save is corect;

   so I read the source ,I find same bugs; 
  memcachedsessionservice.java  the function findSession , I modify it; 

    public MemcachedBackupSession findSession( final String id ) throws IOException {
        MemcachedBackupSession result = _manager.getSessionInternal( id );
        if ( result != null ) {
            // TODO: document ignoring requests and container managed authentication
            // -> with container managed auth protected resources should not be ignored  && !isContainerSessionLookup()
            // TODO: check ignored resource also below
            _log.info( " log==== findSession"  );
            if (!_sticky && !_trackingHostValve.isIgnoredRequest() ) {
            _log.info( "log==== findSession ok"  );                  result.registerReference();
            }
        }

 I modify it, then test is very good.

some one can tell me  is my method  right?

Original issue reported on code.google.com by xueshufe...@163.com on 17 Sep 2012 at 2:28

GoogleCodeExporter commented 8 years ago

if (!_sticky && !_trackingHostValve.isIgnoredRequest() && 
!isContainerSessionLookup()
) 

I modify it such:

if (!_sticky && !_trackingHostValve.isIgnoredRequest() )

Original comment by xueshufe...@163.com on 17 Sep 2012 at 2:32

GoogleCodeExporter commented 8 years ago
The best would be to have a test that reproduces the issue to see if there is 
an issue and if this is a valid fix.
NonStickySessionsIntegrationTest contains several tests that cover cases like 
this 
(https://github.com/magro/memcached-session-manager/blob/master/core/src/test/ja
va/de/javakaffee/web/msm/integration/NonStickySessionsIntegrationTest.java).

Original comment by martin.grotzke on 17 Sep 2012 at 8:01

GoogleCodeExporter commented 8 years ago
the function testParallelRequestsDontCauseDataLoss and 
testParallelRequestsToSameTomcatInstanceIssue111  may use http1.1, it must 
use connection : keep-alive。

my application use nginx+tomcat。 nginx use “connection:close” default。
my pressure test result is:
connect:close,      failure rate is 50%
connect:keep-alive, failure rate  is 4%
when connect:keep-alive, failure rate is  small, the test case maybe 
don't cover it。

Original comment by xueshufe...@163.com on 18 Sep 2012 at 2:25

GoogleCodeExporter commented 8 years ago
So the test has to be altered to also test with connection:close, right? I'll 
check this as soon as I have time (right now I'm under high workload), of 
course you're also invited to change/extend the test to make this issue 
reproducable / testable.

Original comment by martin.grotzke on 18 Sep 2012 at 9:32

GoogleCodeExporter commented 8 years ago
Hi,

Am facing the same issue in multiple tabs and raised a defect here issue 
id(164).
Even though changing the code  to
if (!_sticky && !_trackingHostValve.isIgnoredRequest() )
in memcachedsessionservice.java am facing the issue. Please help me.

Original comment by shaikirf...@gmail.com on 25 May 2013 at 1:13

GoogleCodeExporter commented 8 years ago
xueshuf...,
Hello, I saw you issue. Could I ask you some question ?

Original comment by zheng.gu...@gmail.com on 11 Nov 2014 at 8:03

GoogleCodeExporter commented 8 years ago
Issues are moved to github, this one is now 
https://github.com/magro/memcached-session-manager/issues/192.

Original comment by martin.grotzke on 24 Aug 2015 at 5:07