<p>solicitar obter ESOCKETTIMEDOUT</p>

Criado em 3 jun. 2017  ·  24Comentários  ·  Fonte: request/request

env:

node version v7.10.0
uname -a
Linux iZ2zebqg2v1h2g7jmo9endZ 3.10.0-514.6.2.el7.x86_64 #1 SMP Thu Feb 23 03:04:39 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
request package version: "request": "^2.74.0"

e use expresso: 4.13.4 ,
Eu encontro algum log:

{ Error: ESOCKETTIMEDOUT
       at ClientRequest.<anonymous> (/data1/baas_server/baas_x37/node_modules/request/request.js:819:19)
       at Object.onceWrapper (events.js:293:19)
       at emitNone (events.js:86:13)
       at ClientRequest.emit (events.js:188:7)
       at Socket.emitTimeout (_http_client.js:679:10)
       at Object.onceWrapper (events.js:293:19)
       at emitNone (events.js:86:13)
       at Socket.emit (events.js:188:7)
       at Socket._onTimeout (net.js:352:8)
       at ontimeout (timers.js:386:14)
       at tryOnTimeout (timers.js:250:5)
       at Timer.listOnTimeout (timers.js:214:5) code: 'ESOCKETTIMEDOUT', connect: false }

Eu olho o código-fonte, obtenho muitas anotações:

 var setReqTimeout = function() {
      // This timeout sets the amount of time to wait *between* bytes sent
      // from the server once connected.
      //
      // In particular, it's useful for erroring if the server fails to send
      // data halfway through streaming a response.
      self.req.setTimeout(timeout, function () {
        if (self.req) {
          self.abort()
          var e = new Error('ESOCKETTIMEDOUT')
          e.code = 'ESOCKETTIMEDOUT'
          e.connect = false
          self.emit('error', e)
        }
      })
    }

então eu quero saber por que o motivo e como consertar o bug;
e não sei como acioná-lo, só encontro no log ou encontro a solicitação com erro;
obrigado;

Comentários muito úteis

Descobri que se houver muitas solicitações assíncronas, essa exceção acontece no linux. A solução alternativa que encontrei é fazer o seguinte:

definindo estas opções:

agent: false, pool: {maxSockets: 100}

Agora, o tempo limite pode estar mentindo, portanto, talvez seja necessário aumentá-lo.

Todos 24 comentários

@ Fov6363 Estou com o mesmo problema, você consertou?

@liujb Eu atualizo redis conf, defina o tempo limite 0

Já resolvi o problema, não é sobre o pedido. O problema do Nginx.

eu também

node ProxyServer.js
start: 0.0.0.0:8080
events.js:182
      throw er; // Unhandled 'error' event
      ^

Error: ESOCKETTIMEDOUT
    at ClientRequest.<anonymous> (/Users/safe/myhktools/node_modules/request/request.js:819:19)
    at Object.onceWrapper (events.js:314:30)
    at emitNone (events.js:105:13)
    at ClientRequest.emit (events.js:207:7)
    at Socket.emitTimeout (_http_client.js:722:34)
    at Object.onceWrapper (events.js:314:30)
    at emitNone (events.js:105:13)
    at Socket.emit (events.js:207:7)
    at Socket._onTimeout (net.js:402:8)
    at ontimeout (timers.js:469:11)

Eu encontrei isso porque o servidor usou o proxy

@liujb Olá, você disse que é problema do Nginx. Como você resolve esse problema?

ESOCKETTIMEDOUT é tempo limite de conexão ou tempo limite de leitura?
200 solicitação / s, surge este erro servial.

Descobri que se houver muitas solicitações assíncronas, essa exceção acontece no linux. A solução alternativa que encontrei é fazer o seguinte:

definindo estas opções:

agent: false, pool: {maxSockets: 100}

Agora, o tempo limite pode estar mentindo, portanto, talvez seja necessário aumentá-lo.

Eu tenho esse erro, às vezes com outro erro.

Error: read ECONNRESET
at exports._errnoException (util.js:1034:11)
at TLSWrap.onread (net.js:580:26)

Alguém ainda está tendo esse problema? Estou enviando muitos pedidos de uma vez e estou recebendo.

O mesmo é aqui - com uma única solicitação de colocação para o trabalhador baseado no nó expresso.
Sem proxy, sem streaming, apenas uma única solicitação que inicia várias promessas assíncronas que lidam com o banco de dados no lado do trabalhador.

Agente sugerido: false, pool: {maxSockets: 100} nas opções de solicitação não ajudou.

Alguma sugestão de mantainers?

agent: false, pool: {maxSockets: 100}
Depois de definir as opções acima, os erros reduzem de 55 para 8.
E então eu defino m axSockets: 200 . sobrou apenas um erro
Eu não sei o motivo, mas funciona

Acontece comigo request 2.88.0 , ocasionalmente obtemos ESOCKETTIMEDOUT para aquelas solicitações que foram enviadas de nosso aplicativo e foram processadas ao receber a peça com código de status 200. Parece um bug em algum lugar entre os módulos de solicitação ou https. Novamente, a lib de solicitação lança uma exceção à solicitação de https que é processada com código de status 200 http. Todas as ideias são bem-vindas. O problema é facilmente reproduzível do nosso lado (a cada 200 pedidos falham), então, se vocês estiverem interessados, posso fornecer mais detalhes.

PS Fizemos uma solução alternativa implementando novas tentativas para solicitações com falha.

Oi,
A documentação diz que há "tempo limite de conexão e tempo limite de leitura".
Existe uma maneira de definir cada um deles separadamente?

Estou tendo um tempo limite de conexão às vezes devido a um problema de rede não identificado e gostaria de atingir o tempo limite o mais rápido possível para poder repetir a solicitação sem ter que esperar o tempo limite total que considera o tempo para receber a resposta .
Obrigado.

corrigir para:

EventEmitter = require('events').EventEmitter
EventEmitter.prototype._maxListeners = n_maxLs;
var _fnNull = function(e){if(program && program.verbose)console.log(e)};
process.on('uncaughtException', _fnNull);
process.on('unhandledRejection', _fnNull);

EventEmitter.defaultMaxListeners = n_maxLs;
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0;

@MumiaIrrequieta @anosulchik @deluo

corrigir para:

EventEmitter = require('events').EventEmitter
EventEmitter.prototype._maxListeners = n_maxLs;
var _fnNull = function(e){if(program && program.verbose)console.log(e)};
process.on('uncaughtException', _fnNull);
process.on('unhandledRejection', _fnNull);

EventEmitter.defaultMaxListeners = n_maxLs;
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0;

@MumiaIrrequieta @anosulchik @deluo

Como isso ajuda a definir tempos limites separados?
Qual é a diferença entre as últimas linhas?

Não parece uma correção para ESOCKETTIMEDOUT para mim também. @hktalent você pode dar mais informações sobre isso, por favor?

Também tendo esse problema. Eu envio milhares de solicitações a cada minuto; após cerca de 1 semana de execução de todas as conexões, comece imediatamente a responder com ESOCKETTIMEDOUT .

@ SirLancelot-OG você resolveu?

Eu pesquiso dados a cada minuto, parece que algumas APIs ficaram esporadicamente lentas e fazendo com que a solicitação total ultrapassasse um minuto, o que se acumulou e levou a tempos limite. Não tinha o registro adequado no local.

Agora mudei para usar websockets para meus dados!

Eu recebo esse problema com cada solicitação de forma consistente. Vou fazer um pedido e o pedido é canalizado e concluído. Mas se o tempo limite for de 10 segundos, permitirei obter um 'ESOCKETTIMEDOUT' após 10 segundos de uma única solicitação.

Alguém consertou isso?

Já resolvi o problema, não é sobre o pedido. O problema do Nginx.

como resolver o problema do Nginx

Estamos tendo isso e ele está falhando em compilações ... o que é essa solução misteriosa e mística do nginx ??

Esta página foi útil?
0 / 5 - 0 avaliações