Gerenciador de sessão do Memcached no Azure: a conexão é fechada à força

Question

Estou usando o Gerenciador de sessão do Memcached para lidar com as sessões do Tomcat no modo não-colante . Minha implantação no Azure consiste em uma função de trabalho com duas instâncias que se conectam a uma VM do Azure executando meu servidor do Memcached.

Tudo funciona muito bem, minha sessão é persistida e recuperada por qualquer uma das duas instâncias de forma transparente. O problema surge quando a sessão está inativa por aproximadamente 4 minutos ; tudo indica que o Carregador de Carga do Azure está fechando a conexão do spymemcached com a VM após algum período de inatividade.

Minha configuração do MSM é esta:

<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"/>

O stacktrace impresso pelo cliente spymemcached é este:

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) 

Dada essa limitação de tempo ocioso no Azure, há alguma outra maneira de fazer o MSM funcionar na nuvem azul?

    

Answer 1

Não há nada disponível para resolver isso fora da caixa. Mas você pode criar subclasses de MemcachedBackupSessionManager e usar o método backgroundProcess (que é chamado pelo tomcat a cada segundo ou a cada 10 segundos, sem ter certeza disso) para executar ping em seus memcacheds configurados. Uma implementação muito simples se parece com isso:

package de.javakaffee.web.msm;

public class MyMsm extends MemcachedBackupSessionManager {

    @Override
    public void backgroundProcess() {
        super.backgroundProcess();
        final MemcachedNodesManager nodesManager = _msm.getMemcachedNodesManager();
        // got through all configured node ids and ping each memcached
        // with a dummy key.
        // _msm.newSessionId("ping") generates e.g. ping-n1 for a nodeId n1
        // so this will be routed the related memcached node
        for (String nodeId : nodesManager.getPrimaryNodeIds()) {
            // use async here so that no error handling is needed
            _msm.getMemcached().asyncGet(_msm.newSessionId("ping"));
        }
    }
}

Então você coloca essa classe em jar, coloca o jar em $ CATALINA_HOME / lib além de msm jars e muda o nome da classe Manager para className="de.javakaffee.web.msm.MyMsm" .

Se você gosta, também pode bifurcar o msm e colocar um pedido pull com uma adição que torne isso configurável: -)