Назад | Перейти на главную страницу

Диспетчер сеансов Memcached в Azure: соединение принудительно закрывается

Я использую Memcached Session Manager для обработки сеансов Tomcat в нелипком режиме. Мое развертывание в Azure состоит из рабочей роли с двумя экземплярами, которые подключаются к виртуальной машине Azure, на которой запущен мой сервер Memcached.

Все работает очень хорошо, мой сеанс сохраняется и прозрачно извлекается любым из двух экземпляров. Проблема возникает, когда сеанс простаивает около 4 минуты; все указывает на то, что Azure Loadbalancer закрывает соединение spymemcached с виртуальной машиной после некоторого периода бездействия.

Моя конфигурация MSM такова:

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

След стека, напечатанный клиентом spymemcached, выглядит следующим образом:

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) 

Учитывая это ограничение времени простоя в Azure, есть ли другой способ заставить MSM работать в лазурном облаке?

Нет ничего доступного, чтобы решить эту проблему из коробки. Но вы можете создать подкласс MemcachedBackupSessionManager и использовать backgroundProcess (который вызывается tomcat каждую секунду или каждые 10 секунд, не уверен в этом) для проверки связи с настроенными кешами памяти. Очень простая реализация выглядит так:

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"));
        }
    }
}

Затем вы загружаете этот класс, помещаете банку в $ CATALINA_HOME / lib помимо файлов MSM и меняете имя класса Manager на className="de.javakaffee.web.msm.MyMsm".

Если вам нравится, вы также можете создать вилку msm и разместить запрос на перенос с добавлением, которое делает это настраиваемым :-)