Не удается масштабировать socket.io локально, скорее всего из-за хранилища сеансов

Question

У меня есть главный процесс, который разветвляет рабочих, которые являются серверами socket.io, и все это, используя модуль кластера и, конечно, socket.io.

Проблема в том, что, если я не скажу, что я хочу только одного работникамой код просто не работает.Я написал его до того, как существовал модуль кластера, и он работал нормально как один процесс, и кажется, что теперь он такой же.

Что происходит, когда он разветвляется на 4 рабочих (число ядер ЦП) с RedisStore в качестве сеансаХранилище выглядит следующим образом:

node_redis: no callback to send error: Error: ERR wrong number of arguments for 'hset' command
Caught exception: Error: Error: ERR wrong number of arguments for 'hset' command

И если я использую хранилище памяти по умолчанию, в журналах socket.io оно повторяется

   debug - cleared close timeout for client 3883988821204831830
   debug - discarding transport
   debug - client authorized
   info  - handshake authorized 12039436321106971132
   debug - xhr-polling received data packet �43�5:::{"name":"estimatepp","args":[70821530]}�20�5:::{"name":"ready"}
   debug - setting request GET /socket.io/1/xhr-polling/217474157959916242?t=1328357263590
   debug - setting poll timeout
   debug - clearing poll timeout
   debug - xhr-polling writing 7:::1+0
   debug - set close timeout for client 217474157959916242
   warn  - client not handshaken client should reconnect
   info  - transport end

И на стороне клиента (браузер) регистрирует еговыдает странную ошибку:

Uncaught TypeError: Property 'open' of object #<c> is not a function
handshake.c.sessionidsocket.io.js:2
d.ready

Ошибка на стороне клиента не возникает с RedisStore, и ни одна из ошибок не возникает только с одним работником.У меня есть веские основания полагать, что ошибка wrong number of arguments for 'hset' есть в коде RedisStore файла socket.io, потому что я вообще не использую hset в своем коде, и, опять же, этого не происходит с MemoryStore ...

Как вы думаете, что это происходит?Стоит ли сообщать об этом ребятам из socket.io?

Answer 1

У меня похожая проблема ... Хотя я не получаю никаких ошибок на стороне клиента, особенно на устройствах Android - как в веб-браузере, так и в собственном браузере.В моем случае я использую кодировку UTF-8 в передаваемых данных.Я обнаружил, что в тот момент, когда я отправляю любой кириллический текст / данные, сообщение отправляется должным образом, однако сразу после этого транспорт отбрасывается:

   debug - set close timeout for client 8983972932106614064
   debug - discarding transport
   debug - cleared close timeout for client 8983972932106614064
   debug - xhr-polling received data packet �88�5:::...

Я полагаю, что это весьма вероятно, проблемахранилище REDIS.

Кстати, может быть, если вы заметили, что xhr-опрос получил пакет данных, хранилище redis (я полагаю) отправляет еще один запрос с именем «ready» ... То же самое здесь ... У меня естьдва запроса после блокировки одной и той же проблемы ...