- Navios
- 4 de setembro de 2026 às 20:20 UTC
- Autor
- Kamo
- Enviar
- 6ef1e59
MediaService só executou uma única réplica, então uma implantação dela foi um total bate-papo e Um OOM era o mesmo. Não foi possível executar dois, por razões que estavam todas no código: 1. O stomp broker está no coração. habilitarSimpleBroker significa converterAndSend atinge apenas o WebSockets ligado à cápsula a fazer a chamada. Treze controladores de relé já lidaram com isso corretamente assinando o NATS com um expedidor simples (sem grupo de fila, então cada pod recebe cada mensagem) e re-publicando localmente. Treze outros sítios de chamadas não — indicadores de tipografia, presença, emblemas não lidos, subsídios de resposta, oferta/resposta/ICE WebRTC, notificações de bate-papo recebidas – e cada um teria entregue à metade da audiência pretendida. StompFanout generaliza o padrão que os relés já usam: publicar {destino, carga} em Um assunto central da NATS, cada cápsula retransmite para o seu próprio corretor. Core NATS, não JetStream, porque estes são eventos de momento ao vivo sem valor reproduzido e sem fluxo cobrindo o assunto. Como o núcleo NATS também entrega ao editor, send() NÃO escreve localmente também — que Entregaria duas vezes aqui. Com NATS para baixo ele cai de volta a um envio local, que é o que o A plataforma já o fez antes. 2. O consumidor por conversação era um durável exclusivo. ChatSessionSubscriptionManager nomeou seu JetStream durável após a sessão de chat GUID, e um consumidor de push durável admite exatamente um assinante. A ligação da segunda cápsula foi recusada [SUB-90012] e cada membro cuja tomada pousou não recebeu nada — nenhuma mensagem, nenhum recibo de leitura, nenhum evento associado, nenhum erro. Agora um consumidor efêmero: nenhum nome para colidir, um por pod, colhido pelo servidor. A repetição desta remoção inventou um novo nome durável na colisão. Funcionou, e vazou um consumidor permanente do lado do servidor por colisão que nada apagou. 3. 5 MAIS FIXED-NAME DURÁVEIS, necessitando de tratamento oposto dependendo do trabalho. A conversão e os relés STOMP VOIP passaram pelo JetStream em vez de um despachante de núcleo, então eles tinham o mesmo bug de exclusividade — agora efêmero, já que cada vagem deve receber. O notificador de chat-email, social o consumidor de conversão de consumo e de comercialização deve funcionar exactamente uma vez, de modo a manter a sua duráveis e junte-se a um grupo de entrega, o que também significa que um sobrevivente pega o trabalho quando uma cápsula morre. Sessões fixas na rota de mídia são necessárias, não opcional: estes clientes STOMP usam SockJS, cujo backback xhr-streaming/xhr-polling é várias solicitações HTTP para uma conexão contra o estado de sessão que vive na memória de uma cápsula. O Round-Robin parte-o. Ver entradaroute.yaml. réplicas 1 -> 2. 367 testes passam.