search

bossadvisors / memcached-session-manager

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

Problem with multiple Session Cookies and non sticky mode #156

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I'm using the current Version 1.6.3 of msm and having a Problem within a multi 
context/tomcat environment. My first context is located under "/" on tomcat 1 
with the default Tomcat Manager. My second context is located under "/context2" 
and is using MSM on tomcat2. If both context's added a JSESSION Cookie the 
client will send a HTTP header like: "Cookie: JSESSIONID=context2id; 
JSESSIONID=context1id"

The Problem occurs on the header parsing on 
org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId because the 
org.apache.catalina.connector.Request.isRequestedSessionIdValid will always 
return false. This is caused by the findSession method that will always return 
null on invocations without a request object. The result is that the second 
JSESSIONID is assigned to the request object, but msm is unable to handle it, 
because the session is located on another tomcat.

So, is there a reason for returning null? The assumtions that are made on the 
comments (MemcachedSessionService:579 and 589) are completely wrong:
"we can return just null as the requestedSessionId will still be set on the 
request." and "here we can just return null, the requestedSessionId will be 
accepted anyway".

Original issue reported on code.google.com by hajo.kli...@gmail.com on 4 Feb 2013 at 9:45

GoogleCodeExporter commented 9 years ago 
btw: i'm using tomcat 7.0.23

Original comment by hajo.kli...@gmail.com on 4 Feb 2013 at 9:47

GoogleCodeExporter commented 9 years ago 
Right, this scenario was not tested. The motivation not to load the session 
from memcached in this cases was to support requests that don't access the 
session without loading the session from memcached (performance optimization).
When changing this it would be good to be able to restore the former behaviour 
via configuration.

Right now I'm very loaded, but pull requests that can be merged right away are 
always welcome.

Original comment by martin.grotzke on 5 Feb 2013 at 10:52

GoogleCodeExporter commented 9 years ago 
since this is a problem for us and we want to be update confirmant, it is 
possible to finish the current dev cycle and release 1.6.4 after i submitted 
the changes?

Original comment by hajo.kli...@gmail.com on 5 Feb 2013 at 11:27

GoogleCodeExporter commented 9 years ago 
If all tests are green then yes

Original comment by martin.grotzke on 5 Feb 2013 at 11:58

GoogleCodeExporter commented 9 years ago 
@hajo.kliemeck.mmw Just to be sure: this is still an issue and not yet resolved 
by your pull requests, right?

Original comment by martin.grotzke on 15 Jun 2013 at 10:53

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
@martin.grotzke correct, the issue is not solved by my changes. but its not 
longer an issue for me

Original comment by hajo.kli...@gmail.com on 16 Jun 2013 at 8:59

GoogleCodeExporter commented 9 years ago 
Ok

Original comment by martin.grotzke on 18 Jun 2013 at 3:07

GoogleCodeExporter commented 9 years ago 
This is an issue at my setup, exactly the same issue, but getting an exception 
now.

Original comment by crudolf....@googlemail.com on 24 Sep 2013 at 9:02

GoogleCodeExporter commented 9 years ago 
I changed the related code, so that sessions are now always loaded from 
memcached. Can you test this with the attached jar (compatible to 1.6.5)?

Original comment by martin.grotzke on 24 Sep 2013 at 9:53

Attachments:

GoogleCodeExporter commented 9 years ago 
I think it is more stable. However two issues remain:
1. I log in at an app running at "/" (Cookie Path is "/")
2. I log in at an app running at "/XY" (Cookie Path is "/XY")
3. I log out at "/XY"
4. I am still logged in, because the app is somehow retrieving the wrong 
session or cookie, because I am then logged in with the user from 1)

Summary: An app running at "/XY" is retrieving the session/cookie from another 
app at "/"

Second issue: If I do not use the app for a while, I retrieve this error. I 
guess this might be a configuration issue:

2013-09-28 14:10:02.045 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting due to exception on {QA sa=localhost/127.0.0.1:11212, #Rops=1, 
#Wops=0, #iq=0, topRop=Cmd: get Keys: ping-zfExp: 0, topWop=null, toWrite=0, 
interested=1}
java.io.IOException: Disconnected unexpected, will reconnect.
        at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
        at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:454)
        at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
        at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-09-28 14:10:02.046 WARN net.spy.memcached.MemcachedConnection:  Closing, 
and reopening {QA sa=localhost/127.0.0.1:11212, #Rops=1, #Wops=0, #iq=0, 
topRop=Cmd: get Keys: ping-zfExp: 0, topWop=null, toWrite=0, interested=1}, 
attempt 0.
2013-09-28 14:10:02.047 WARN 
net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl:  Discarding partially 
completed op: Cmd: get Keys: ping-zfExp: 0
Sep 28, 2013 2:10:02 PM de.javakaffee.web.msm.MemcachedSessionService 
changeSessionIdOnMemcachedFailover
Information: Session needs to be relocated as node zf is not available, loading 
backup session for 030666B54CCDA2501A7B704EA6CA1B1A-zf
Sep 28, 2013 2:10:02 PM de.javakaffee.web.msm.MemcachedSessionService 
loadBackupSession
Information: No next available node found for nodeId zf
2013-09-28 14:10:02.108 WARN net.spy.memcached.MemcachedConnection:  handling 
node for operation is not set
2013-09-28 14:10:02.114 WARN net.spy.memcached.MemcachedConnection:  handling 
node for operation is not set
Sep 28, 2013 2:10:02 PM de.javakaffee.web.msm.LockingStrategy 
onBackupWithoutLoadedSession
Warnung: An error when trying to load/update validity info.
java.util.concurrent.CancellationException: Cancelled
        at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:170)
        at net.spy.memcached.internal.GetFuture.get(GetFuture.java:62)
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1026)
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1051)
        at de.javakaffee.web.msm.LockingStrategy.loadSessionValidityInfoForValidityKey(LockingStrategy.java:331)
        at de.javakaffee.web.msm.LockingStrategy.onBackupWithoutLoadedSession(LockingStrategy.java:229)
        at de.javakaffee.web.msm.MemcachedSessionService.backupSession(MemcachedSessionService.java:1054)
        at de.javakaffee.web.msm.RequestTrackingHostValve.backupSession(RequestTrackingHostValve.java:245)
        at de.javakaffee.web.msm.RequestTrackingHostValve.invoke(RequestTrackingHostValve.java:174)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
        at org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:335)
        at org.apache.catalina.ha.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:219)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
        at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1810)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)

FYI: zf is the name of the memcache node (which is running at another host, 
connected via autossh).

Original comment by crudolf....@googlemail.com on 28 Sep 2013 at 12:12

GoogleCodeExporter commented 9 years ago 
For the first part (4.: still logged in / wrong session cookie ), this is issue 
#173. This is on the top of my todo list - sessions/objects must be saved in 
memcached with the context path as prefix.

Regarding the second part (IOException: Disconnected unexpected, will 
reconnect): this might be a network issue, maybe it would be better addressed 
at the spymemcached list/forum, you could also start opening a separate issue 
here. You should provide more details like e.g. your configuration, the 
networking setup, how often it happens etc.

Original comment by martin.grotzke on 29 Sep 2013 at 7:40

GoogleCodeExporter commented 9 years ago

Original comment by martin.grotzke on 29 Sep 2013 at 7:42

GoogleCodeExporter commented 9 years ago 
When will the fix for this issue be available so that sessions always get 
loaded from memcached instead of returning null if the request is from 
CoyoteAdapter.postParseRequest?

Original comment by sgonagun...@demandforce.com on 10 Apr 2014 at 5:47

GoogleCodeExporter commented 9 years ago 
Can you test if the attached version is working for you?

Original comment by martin.grotzke on 10 Apr 2014 at 8:44

Attachments:

GoogleCodeExporter commented 9 years ago 
Can you provide memcached-session-manager-tc6-1.8.2-SNAPSHOT.jar since we are 
using tomcat 6 for our web application?

Original comment by sgonagun...@demandforce.com on 10 Apr 2014 at 10:20

GoogleCodeExporter commented 9 years ago 
Attached.

Original comment by martin.grotzke on 11 Apr 2014 at 3:04

Attachments:

GoogleCodeExporter commented 9 years ago 
yes its working fine with the provided jars

Original comment by sgonagun...@demandforce.com on 14 Apr 2014 at 4:55

GoogleCodeExporter commented 9 years ago 
When can we expect 1.8.2 version to be available?

Original comment by sgonagun...@demandforce.com on 14 Apr 2014 at 5:13

GoogleCodeExporter commented 9 years ago 
There were still test failures, so this needs more investigation. Sorry that 
this didn't make it into 1.8.2.

From running the tests I'm also seeing this error:
java.lang.RuntimeException: There's no request set, this indicates that this 
findSessionwas triggered by the container which should already be handled in 
findSession.
        at de.javakaffee.web.msm.LockingStrategyAuto.onBeforeLoadFromMemcached(LockingStrategyAuto.java:124)
        at de.javakaffee.web.msm.MemcachedSessionService.loadFromMemcached(MemcachedSessionService.java:1082)
        at de.javakaffee.web.msm.MemcachedSessionService.findSession(MemcachedSessionService.java:586)
        at de.javakaffee.web.msm.MemcachedBackupSessionManager.findSession(MemcachedBackupSessionManager.java:222)
        at org.apache.catalina.connector.Request.isRequestedSessionIdValid(Request.java:2221)
        at org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:761)
        at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:574)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        at java.lang.Thread.run(Thread.java:744)
which also needs to be checked.

Original comment by martin.grotzke on 15 Jun 2014 at 11:35

GoogleCodeExporter commented 9 years ago 
Hi Martin,

I've just faced this bug as well (Tomcat 7.0.50 + msm 1.8.2 + non-sticky 
sessions):

        <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
                memcachedNodes="localhost:11211"
                requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js|woff)$"
                transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
                sessionBackupAsync="true"
                sticky="false"
                copyCollectionsForSerialization="false"
        />

Voting to get this issue fixed.

Thanks,
Sergey

Original comment by sergey.e...@gmail.com on 12 Sep 2014 at 11:16