Memcached session manager in Azure: Connection gets forcibly closed
- by Edgar Pérez
I am using Memcached Session Manager to handle Tomcat sessions in non-sticky mode. My deployment in Azure consists of a Worker Role with two instances which connect to an Azure VM running my Memcached server.
Everything works pretty well, my session is persisted and retrieved by any of the two instances transparently. The problem arises when the session is idle for about 4 minutes; everything points out that the Azure Loadbalancer is closing the spymemcached connection to the VM after some period of inactivity.
My MSM configuration is this:
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:my-azure-vm.cloudapp.net:11211"
sticky="false"
sessionBackupAsync="false"
sessionBackupTimeout="10000"
lockingMode="uriPattern:/path1|/path2"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js|ttf|eot|svg|woff)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
customConverter="de.javakaffee.web.msm.serializer.kryo.HibernateCollectionsSerializerFactory"/>
The stacktrace printed by the spymemcached client is this:
INFO net.spy.memcached.MemcachedConnection: Reconnecting due to
exception on {QA sa=/10.194.132.206:13000, #Rops=1, #Wops=0, #iq=0,
topRop=net.spy.memcached.protocol.binary.StoreOperationImpl@1d95da8,
topWop=null, toWrite=0, interested=1}
java.io.IOException: An existing connection was forcibly closed by the
remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(Unknown Source)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at sun.nio.ch.IOUtil.read(Unknown Source)
at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at net.spy.memcached.MemcachedConnection.handleReads
(MemcachedConnection.java:303)
at net.spy.memcached.MemcachedConnection.handleIO
(MemcachedConnection.java:264)
at net.spy.memcached.MemcachedConnection.handleIO
(MemcachedConnection.java:184)
at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1298)
Given this idle time limitation in Azure, is there any other way to make MSM work in the azure cloud?
