Closed GoogleCodeExporter closed 8 years ago
Can you try increasing the operationTimeout, e.g. to 5000?
Depending on your app you could also try to change sessionBackupAsync to true.
Btw, the sessionBackupTimeout defines how long to wait (block the request)
until a session is written to memcached, it does NOT define the TTL of sessions
in memcached (session timeout).
Original comment by martin.grotzke
on 25 Nov 2013 at 11:55
Thanks for your help, I added the parameter:
<Context path="" docBase="/usr/local/tomcat-XXX/webapps/XXX" sessionCookieDomain=".XXX.com" debug="0" privileged="true" reloadable="true" allowlinking="true">
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:XXX.XXX.XXX.XXX:11211"
requestUriIgnorePattern=".*\.(png|gif|jpg|css|js)$"
sessionBackupAsync="false"
sticky="false"
sessionBackupTimeout="1800000"
operationTimeout="5000"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.json.JSONTranscoderFactory"/>
</Context>
And we try it , tomorrow we will import a lot of users access out site.
Original comment by ache...@gmail.com
on 26 Nov 2013 at 1:53
I changed the config;
sessionBackupAsunc="true“
but the site still print :
Nov 26, 2013 3:47:16 PM de.javakaffee.web.msm.LockingStrategy
onAfterLoadFromMemcached
WARNING: No validity info available for session
6A0FA99E47B4CBAAF1A718650830D6C4-n1
sometimes.
Original comment by ache...@gmail.com
on 26 Nov 2013 at 7:51
I don't know exactly which configuration change caused which change in log
output / behaviour.
What did change after you added operationTimeout="5000"?
what did change after you added sessionBackupAsunc="true" (I assume you still
have set the operationTimeout)?
Can you tell in which configuration which logs are printed how often
(considering the number of requests in total)?
Do you know if "No validity info available for session" is logged for sessions
that were just created (do you know the age of sessions for that this is
logged)?
Have you checked that all machines have set the same time?
Can you reproduce the issue in a local/test environment?
Original comment by martin.grotzke
on 26 Nov 2013 at 11:20
Thank you for your reply.
We used 4 tomcat to run 4 webapps, and the configuration is NOT SAME.
And I looked memcached log:
31 END
<31 get validity:C8026CE4F36C1E3EE29F0058602F9B59-n1
>31 sending key validity:C8026CE4F36C1E3EE29F0058602F9B59-n1
>31 END
<31 set validity:C8026CE4F36C1E3EE29F0058602F9B59-n1 2048 1800 20
>31 STORED
<31 set C8026CE4F36C1E3EE29F0058602F9B59-n1 2048 3600 505
>31 STORED
<31 get ping-n1
>31 END
<31 set validity:003DE48AE9570C5F03D41A0A3C5AC5C4-n1 2048 1800 20
>31 STORED
<31 set 003DE48AE9570C5F03D41A0A3C5AC5C4-n1 2048 3600 102
>31 STORED
<31 get ping-n1
>31 END
<31 get 003DE48AE9570C5F03D41A0A3C5AC5C4-n1
>31 sending key 003DE48AE9570C5F03D41A0A3C5AC5C4-n1
>31 END
<31 get validity:003DE48AE9570C5F03D41A0A3C5AC5C4-n1
>31 sending key validity:003DE48AE9570C5F03D41A0A3C5AC5C4-n1
>31 END
<31 set validity:003DE48AE9570C5F03D41A0A3C5AC5C4-n1 2048 1800 20
>31 STORED
<31 add 003DE48AE9570C5F03D41A0A3C5AC5C4-n1 512 5 1
>31 NOT_STORED
<31 get ping-n1
>31 END
<31 set validity:89B1B5940647DBBA3BB285326C17360B-n1 2048 1800 20
>31 STORED
<31 set 89B1B5940647DBBA3BB285326C17360B-n1 2048 3600 141
>31 STORED
Memcached start cmd:/usr/local/bin/memcached -m 1024 -p 11211 -d -u root -P
/var/run/memcached.pid -vv
Sometimes the log output is NOT_STORED.And when the session is not stored, out
progarm will print NullPointerException.We added to the session some list data
using session.setAttribute();
I will change the tomcat configuration same.
The request maybe just 1000~1500/Hour, and maybe in somecase there are more and
more...then the tomcat will output blow:
java.util.concurrent.ExecutionException:
net.spy.memcached.internal.CheckedOperationTimeoutException: Operation timed
out. - failing node: /127.0.0.1:11211
server1: memcached
/ \ \ \
server2:T1 T2 T3 T4
\ | | /
Nginx(CDN)
four tomecat access is OK,just the T1,when access a lot ,the question happens.
Original comment by ache...@gmail.com
on 27 Nov 2013 at 2:49
Thanks for your suggestion,after change the tomcat configuration same,the
output error disappear.
[root@AY130805154445913356Z logs]# tail -1000f catalina.out | grep "No validity"
警告: No validity info available for session
DE3B70826EC5CE85F31DA3AB936650E7-n1
警告: No validity info available for session
BF0D449FF3F64F062EA2225CEF2B1551-n1
警告: No validity info available for session
D10704DAE5DB7224FAF726D18DF5F67B-n1
And the warning also disappear.
There are the output warnings.
And we have a php site also use the memcached session, it get the session from
memcached, and we are see it's configuration.
server1: memcached----php
/ \ \ \
server2:T1 T2 T3 T4
\ | | /
Nginx(CDN)
Original comment by ache...@gmail.com
on 27 Nov 2013 at 5:51
So you had different system times on different machines?
And now your issues are all solved? Or do you still need s.th. to get
fixed/improved?
FYI: memcached logs like
<31 add 003DE48AE9570C5F03D41A0A3C5AC5C4-n1 512 5 1
>31 NOT_STORED
show "ping" requests (when an http request did not access the session msm pings
the session in memcached) to push up sessions in memcacheds LRU list so that
they are not evicted too early.
Regarding the setup of memcached/tomcat/nginx: your memcached (server1) is a
single point of failure. So if server1 goes down (or you need to restart
memcached) all sessions will be lost.
An alternative setup would be to run memcacheds and tomcats both on server1 and
server2.
E.g. you would have m1, tc1 and tc2 on server1 and m2, tc3 and tc4 on server2.
The memcachedNodes config would look like this:
memcachedNodes="n1:xxx.xxx.xxx.1:11211,n2:xxx.xxx.xxx.2:11211"
See also
https://code.google.com/p/memcached-session-manager/wiki/FAQ#How_are_sessions_st
ored_in_memcached_in_non-sticky_mode?
Original comment by martin.grotzke
on 27 Nov 2013 at 8:33
Thank you very much.
We are improve the structure of the website.
The warning is much less than before, but it also output.
I know the sugguestion you given is useful, today I will configure it.
Original comment by ache...@gmail.com
on 27 Nov 2013 at 10:35
After we configured the tomcat as the same configuration, the warning is less.
The msm is running ok.Thanks for your help.
Original comment by ache...@gmail.com
on 29 Nov 2013 at 5:47
Ok, great that it's working.
Original comment by martin.grotzke
on 29 Nov 2013 at 8:59
Original issue reported on code.google.com by
ache...@gmail.com
on 23 Nov 2013 at 2:00