Shinyproxy: [Relatório de Bug] Erro AJAX na nova versão do ShinyProxy (versão 2.2.0+)

Criado em 28 mar. 2019  ·  46Comentários  ·  Fonte: openanalytics/shinyproxy

Na nova versão de lançamento (2.2.0) do ShinyProxy, todos os aplicativos que usam DT com modo de processamento de servidor serão interrompidos. O navegador reclama de erros de Ajax enquanto o log do ShinyProxy informa que os métodos de solicitação 'Post' não são suportados .

Capturas de tela

屏幕快照 2019-03-28 下午11 24 18
屏幕快照 2019-03-28 下午11 24 32

Um exemplo de aplicativo

library(shiny)
ui <- fluidPage(DT::DTOutput('tbl'))
server <- function(input, output, session) {
  output$tbl <- DT::renderDT(iris, server = TRUE)
}
shinyApp(ui, server)

Na verdade, configurei um exemplo docker-compose para isso, consulte https://github.com/shrektan/shinyproxy-docker-compose-example

bug

Comentários muito úteis

Obrigado! Podemos reproduzir isso e estamos trabalhando nisso.

Todos 46 comentários

Obrigado! Podemos reproduzir isso e estamos trabalhando nisso.

@shrektan, obrigado por relatar o problema.
Uma correção foi confirmada:
https://github.com/openanalytics/containerproxy/commit/6455abdaed031297baf600f5e71e2242b689d940

Você pode, por favor, experimentar este desenvolvimento de desenvolvimento e ver se ele corrige o problema?
https://nexus.openanalytics.eu/nexus/content/repositories/snapshots/eu/openanalytics/shinyproxy/2.2.1-SNAPSHOT/shinyproxy-2.2.1-20190329.093240-2.jar

@fmichielssen Obrigado pela solução rápida. Posso confirmar que tanto o DT quanto fileInput() funcionam bem com a compilação de desenvolvimento.

Obrigado pela confirmação, @shrektan! Lançado como parte do ShinyProxy 2.2.1

Acabei de fazer uma nova instalação com 2.2.1 e estou recebendo o mesmo erro que @shrektan relatou:

Screen Shot 2019-03-31 at 2 27 42 PM

Então, em brilhanteproxy.log, eu obtenho:

2019-03-31 21:27:33.548 ERROR 9925 --- [XNIO-2 I/O-3] io.undertow.proxy                        : UT005028: Proxy request to /proxy_endpoint/b77c8f8f-8dc9-45c3-a858-e12c7e33e159/session/cf6134effe616504495d1d75171f0546/dataobj/de_main_table failed

io.undertow.server.TruncatedResponseException: null
    at io.undertow.client.http.HttpRequestConduit.truncateWrites(HttpRequestConduit.java:711) ~[undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.terminateWrites(AbstractFixedLengthStreamSinkConduit.java:256) ~[undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
    at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:79) ~[undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.ProxyHandler$HTTPTrailerChannelListener.handleEvent(ProxyHandler.java:754) ~[undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:646) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:561) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.client.http.HttpClientExchange.invokeReadReadyCallback(HttpClientExchange.java:212) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:410) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:343) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:561) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:815) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:316) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:290) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:338) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.ProxyConnectionPool.connect(ProxyConnectionPool.java:525) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at io.undertow.server.handlers.proxy.LoadBalancingProxyClient.getConnection(LoadBalancingProxyClient.java:301) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at eu.openanalytics.containerproxy.util.ProxyMappingManager$1.getConnection(ProxyMappingManager.java:88) [containerproxy-0.8.1.jar!/:0.8.1]
    at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.run(ProxyHandler.java:310) [undertow-core-1.4.22.Final.jar!/:1.4.22.Final]
    at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:582) [xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
    at org.xnio.nio.WorkerThread.run(WorkerThread.java:466) [xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]

O que é interessante é que isso afeta outro pacote: brilhanteWidgets. Eu tenho um monte de entradas que são geradas usando insertUI e os valores na lista suspensa destacada abaixo são extraídos de um banco de dados (dinâmico). Ao executar localmente, tudo funciona bem (e eu obtenho os valores reais). Ao implantar no Glossproxy, obtenho NA1, NA2, NA3 ... super estranho.

Screen Shot 2019-03-31 at 2 30 48 PM

Devo mencionar que as coisas estavam funcionando bem no 2.1.0. Caso isso faça diferença, estou usando o Glossproxy atrás do nginx, com um certificado LetsEncrypt.

@bogdanrau Você poderia fornecer um aplicativo de exemplo fictício (semelhante ao @shrektan fornecido) que nos permite reproduzir rapidamente?

Olá @tverbeke, gostaria de saber se agora poderíamos implementar o 2.2.1 - isso foi corrigido?

Olá @dylancis : o problema original foi definitivamente corrigido conforme confirmado por nossos testes e por @shrektan. Para o problema relatado por @bogdanrau , não temos um exemplo reproduzível ainda ou (a confirmação de outro usuário de que o problema ainda é).

@tverbeke , acabei de @shrektan e estou recebendo esse erro. A única diferença que vejo é que estou usando o .deb como um serviço, em vez de usar o arquivo .jar. Alguém está usando o arquivo .deb?

funciona bem aqui com 2.2.1 .

funciona bem aqui com 2.2.1 .

E isso está usando o deb installer ou o arquivo jar? Eu criei uma nova VM do zero usando apenas o arquivo .deb e ainda tinha os mesmos problemas por qualquer motivo.

qual é o arquivo deb?

@shrektan : se você olhar a página de download do Glossproxy (https://www.shinyproxy.io/downloads/), você pode baixar um arquivo independente de plataforma (.jar) ou um arquivo deb específico para o Ubuntu que você instala com dpkg. Eu escolhi isso em vez do arquivo independente de plataforma.

Recebo o mesmo erro de @bogdanrau.
Minha configuração: Estou usando o GlossProxy 2.2.1 (.jar independente da plataforma) por trás do nginx.
Percebi que esse erro ocorre dependendo do método de autenticação escolhido no ShinyProxy. Quando eu uso o exemplo de @shrektan (docker pull shrektan / rdocker4working) junto com nginx, ShinyProxy 2.2.1 e autenticação: simples, tudo funciona bem. Quando eu mudo para autenticação: keycloak, recebo o erro. A própria autenticação Keycloak parece funcionar.

Posso confirmar que também estou usando keycloak com nginx.

Eu também tenho esse problema com a versão> 2.1.0 (última que funciona), mesmo 2.2.1 não funciona para mim.
Eu executo um Brightproxy dockerized que busca o jar independente da plataforma atrás de um proxy reverso Traefik v1.7.12.
Estou usando o keycloak v6.0.1 para autenticação / autorização.
Tive que reverter para a versão 2.1 para poder ver as tabelas de dados com ajax habilitado (servidor = TRUE) quando desabilitado funciona com as versões mais recentes.

Há alguma notícia ou solução alternativa para esse bug?

Eu corro exatamente o mesmo problema e posso confirmar que o problema ocorre em combinação com a autenticação do keycloak .

Estou usando brilhanteproxy-2.3.0.jar em um ambiente dockerizado em uma máquina Ubuntu 18.04.2 LTS. Nginx é usado como proxy reverso em combinação com um certificado ssl letsencrypt.

Aplicativo-exemplo-brilhante:

library(shiny)
library(DT)

ui <- fluidPage(DT::dataTableOutput('tbl'))
server <- function(input, output, session) {
  output$tbl <- DT::renderDataTable(data.frame(Col_1=c(1:10), Col_2=c(11:20)))
}
shinyApp(ui, server)

A tentativa de executar o exemplo superior com brilhanteproxy e keycloak-auth (btw. Executando no mesmo servidor) leva ao erro 503 Service Unavailable AJAX mencionado. Tornar server = FALSE resolve esse erro, mas está fora de questão para mesas grandes.

Exatamente a mesma máquina (docker, shineproxy, nginx setting) com auth ou ldap simples em application.yml rodando sem problemas .

o mesmo problema com Billy 34
em ShinyProxy 2.3.0, use DT :: renderDataTable ainda tem o mesmo erro de ajax 503
use keycloak v7.0.0 para autenticação / autorização
mas reverter para 2.1 funcionará bem

App de exemplo

library(shiny)
ui <- fluidPage(DT::dataTableOutput('tbl'))
server <- function(input, output, session) {
output$tbl <- DT::renderDataTable({
DT::datatable(iris, class = 'cell-border stripe')
})
}

Eu tenho o mesmo TruncatedResponseException mencionado por @bogdanrau com o upload de arquivos para RStudio em execução dentro do Shiny Proxy> 2.1 encaixado (usando o método de autenticação simples). https://github.com/openanalytics/shinyproxy/issues/170

Apenas adicionando um 'eu também'. O problema é com o back-end de autorização do Keycloak e não aparece de outra forma. Reverter para 2.1 funciona conforme o esperado.

Encontrar isso também com KeyCloak Auth e qualquer ShinyProxy versão> 2.1.0

Foi encontrado o mesmo problema no nginx (SSL habilitado) e no serviço de autenticação do keycloak. No entanto, o DT exibe perfeitamente sem keycloak.
Por favor, veja o anexo!

Error-Traceback

Http-Response

Foi encontrado o mesmo problema no nginx (SSL habilitado) e no serviço de autenticação do keycloak. No entanto, o DT exibe perfeitamente sem keycloak.
Por favor, veja o anexo!

Error-Traceback

Http-Response

Jar ShinyProxy 2.3.0 do brilhanteproxy.io

Conseguimos reproduzir com o Keycloak. Uma correção estará na próxima versão.

Conseguimos reproduzir com o Keycloak. Uma correção estará na próxima versão.

Obrigado por reverter!

Obtendo o mesmo erro, sem nenhum tipo de autenticação. Ao fazer uma solicitação POST do tipo de conteúdo: multipart / form-data. Alguma ideia de qual é a diferença entre as duas versões que esse erro está chegando. Por favor, sugira alguma solução caso a reversão não seja uma opção. A propósito, estou executando o frasco atrás do proxy brilhante
Obrigado.

@tverbeke, você poderia gentilmente enviar um instantâneo da filial <dev> com este problema corrigido? talvez os primeiros testes possam descobrir algo mais que precise de uma correção antes de atualizar o branch <stable> .
Desde já, obrigado.

@jaysnm a correção está presente na ramificação de desenvolvimento do containerproxy.

@tverbeke é lamentável que o branch de desenvolvimento da compilação do containerproxy falhou (consulte o anexo). Eu também desenvolvi o branch de
Obrigado.

image

@jaysnm Você precisa compilar com Oracle Java no momento. O construtor na classe sun.security.krb5.KrbTgsReq é diferente entre Oracle Java e OpenJDK e estamos cientes disso.

Com a versão oficial 2.3.1, finalmente funcionou bem para mim. É hora de encerrar esta edição # 140?

Obrigado pelo feedback, @ Dusan-Dingarac

Olá, estou tendo o mesmo problema depois de atualizar do ShinyProxy 2.3.1 para o 2.4.1. Podemos reabrir o bug?

no navegador:
DataTables warning: table id=DataTables_Table_0 - Ajax error. For more information about this error, please see http://datatables.net/tn/7

no Brightproxy
at io.undertow.server.handlers.proxy.ProxyConnectionPool.connect(ProxyConnectionPool.java:548) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.LoadBalancingProxyClient.getConnection(LoadBalancingProxyClient.java:316) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at eu.openanalytics.containerproxy.util.ProxyMappingManager$1.getConnection(ProxyMappingManager.java:88) ~[containerproxy-0.8.5.jar!/:0.8.5] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.run(ProxyHandler.java:310) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) ~[xnio-nio-3.8.0.Final.jar!/:3.8.0.Final] │ │ at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) ~[xnio-nio-3.8.0.Final.jar!/:3.8.0.Final] │ │ 2020-10-23 15:33:30.211 DEBUG 1 --- [ XNIO-1 I/O-2] io.undertow.request.error-response : Setting error code 503 for exchange HttpServerExchange{ POST /system-recommendation-dashboard/pr │ │ oxy_endpoint/3913e3ea-8e4d-4c7a-9bf7-4418b3064b26/session/2baa425f53c271bc590b7d1a0c335a89/dataobj/tab_Cov_Linea_O} │ │ java.lang.RuntimeException: null │ │ at io.undertow.server.HttpServerExchange.setStatusCode(HttpServerExchange.java:1416) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler.handleFailure(ProxyHandler.java:668) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$HTTPTrailerChannelListener.handleEvent(ProxyHandler.java:769) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:646) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:561) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientExchange.invokeReadReadyCallback(HttpClientExchange.java:212) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:414) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:561) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:821) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:316) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:290) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:353) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyConnectionPool.connect(ProxyConnectionPool.java:548) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.LoadBalancingProxyClient.getConnection(LoadBalancingProxyClient.java:316) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at eu.openanalytics.containerproxy.util.ProxyMappingManager$1.getConnection(ProxyMappingManager.java:88) ~[containerproxy-0.8.5.jar!/:0.8.5] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.run(ProxyHandler.java:310) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) ~[xnio-nio-3.8.0.Final.jar!/:3.8.0.Final] │ │ at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) ~[xnio-nio-3.8.0.Final.jar!/:3.8.0.Final]

Estou tendo o mesmo problema com DT sem ShinyProxy com balanceamento de carga usando traefik como proxy reverso. Talvez vinculado ao DT e balanceamento de carga?
Preciso investigar do meu lado
Você já viu esse problema https://github.com/rstudio/DT/issues/849 ?

Também estou usando o traefik como balanceador de carga, mas voltei para 2.3.1 e funciona bem, com 2.4.0 e 2.4.1 dá esse erro.

Oi @giordyb

Acabei de testar o código de exemplo na primeira postagem desta edição com ShinyProxy 2.4.1 e ainda funciona para mim.
Você pode compartilhar as seguintes informações:

  • o código do aplicativo Shiny que você está usando
  • a configuração do Traefik
  • talvez um arquivo docker-compose para que eu possa testar facilmente sua configuração

Preciso de pelo menos as duas primeiras peças, caso contrário, não poderei reproduzir o exemplar.
Obrigado

Basta adicionar meus dois centavos aqui. A fim de garantir que o DT funcione por trás de um balanceador de carga (Traefik), criei recentemente um balanceador de carga DT de repo simples baseado no Docker Swarm, com configurações detalhadas ... Acho que com um pouco de esforço, você pode transformá-lo em um reproduzível exemplo para ShinyProxy sobre este problema ...

@giordyb Resolvi meu problema com traefik e balanceamento de carga. Ainda estou usando o traefik 1.7 (1.7.26) e ainda há um problema com a configuração de aderência. Eu estava usando o rótulo "traefik.backend.loadbalancer.stickiness" conforme documentado, mas sem sucesso. O uso do rótulo obsoleto "traefik.backend.loadbalancer.sticky = true" está funcionando. Não sei se é uma pista para esse problema, mas quem sabe.

@ billy34 obrigado, estou rodando o traefik 2.2, tentei habilitar a sessão pegajosa mas não fez diferença. Vou postar meu código e configuração do traefik em breve

@LEDfan Estou executando o traefik no kubernetes (em um cluster de vários nós), por isso é um pouco complicado replicar nosso ambiente com um docker-compose.
Consegui criar um ambiente menor com um único nó do Kubernetes no docker (docker para mac) e ainda dá erros.

aqui está o código do aplicativo (é apenas uma amostra, mas também apresenta erros):
_edit: veja a próxima postagem para o código_

Eu testei esta versão deste aplicativo com esta configuração do traefik sob o brightproxy 2.3.0 e funciona, se eu tentar a mesma coisa no 2.4.1 eu obtenho o erro

Outra coisa que eu tentei é ignorar o traefik redirecionando a porta diretamente para o container shineproxy, mesmo fazendo isso o erro apareceu, então eu realmente duvido que seja um problema do traefik.

@LEDfan

Fiz mais alguns testes, parece que traefik não tem nada a ver com isso.

Eu criei um repo que replica meu ambiente (https://github.com/giordyb/test_shinyproxy.git)

no docker para mac executando kubernetes, criei 2 implantações de proxy brilhante (2.3.1 e 2.4.1) que atendem ao mesmo aplicativo de contêiner R brilhante.
Não há traefik envolvido, os pods proxy brilhantes são acessados ​​por meio de um encaminhamento de porta kube-proxy.

sob 2.3.1 a solicitação para os trabalhos datáveis

sob 2.4.1 a mesma solicitação falha

e eu recebo isso no log do contêiner Brightproxy
2020-10-26 15:17:46.359 ERROR 1 --- [ XNIO-1 I/O-2] io.undertow.proxy : UT005028: Proxy request to /proxy_endpoint/884afa30-73a0-444f-b04f-3ae85b6de6bd/session/aacc55466aefc00eabd04b31f9891242/dataobj/tab_Cov_Linea_O failed │ │ io.undertow.server.TruncatedResponseException: null │ │ at io.undertow.client.http.HttpRequestConduit.truncateWrites(HttpRequestConduit.java:711) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.terminateWrites(AbstractFixedLengthStreamSinkConduit.java:256) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178) ~[xnio-api-3.8.0.Final.jar!/:3.8.0.Final] │ │ at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:79) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$HTTPTrailerChannelListener.handleEvent(ProxyHandler.java:754) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:646) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:561) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientExchange.invokeReadReadyCallback(HttpClientExchange.java:212) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:414) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:561) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:821) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:316) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:290) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:353) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyConnectionPool.connect(ProxyConnectionPool.java:548) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.LoadBalancingProxyClient.getConnection(LoadBalancingProxyClient.java:316) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at eu.openanalytics.containerproxy.util.ProxyMappingManager$1.getConnection(ProxyMappingManager.java:88) ~[containerproxy-0.8.5.jar!/:0.8.5] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.run(ProxyHandler.java:310) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) ~[xnio-nio-3.8.0.Final.jar!/:3.8.0.Final] │ │ at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) ~[xnio-nio-3.8.0.Final.jar!/:3.8.0.Final] │ │ 2020-10-26 15:17:46.361 DEBUG 1 --- [ XNIO-1 I/O-2] io.undertow.request.error-response : Setting error code 503 for exchange HttpServerExchange{ POST /proxy_endpoint/884afa30-73a0-444f-b04f-3ae85b6de6bd/session/aacc55466aefc00eabd04b31f9891242 │ │ java.lang.RuntimeException: null │ │ at io.undertow.server.HttpServerExchange.setStatusCode(HttpServerExchange.java:1416) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler.handleFailure(ProxyHandler.java:668) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$HTTPTrailerChannelListener.handleEvent(ProxyHandler.java:769) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:646) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:561) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientExchange.invokeReadReadyCallback(HttpClientExchange.java:212) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:414) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:561) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:821) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:316) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:290) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:353) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.ProxyConnectionPool.connect(ProxyConnectionPool.java:548) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at io.undertow.server.handlers.proxy.LoadBalancingProxyClient.getConnection(LoadBalancingProxyClient.java:316) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at eu.openanalytics.containerproxy.util.ProxyMappingManager$1.getConnection(ProxyMappingManager.java:88) ~[containerproxy-0.8.5.jar!/:0.8.5] │ │ at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.run(ProxyHandler.java:310) ~[undertow-core-2.1.4.Final.jar!/:2.1.4.Final] │ │ at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) ~[xnio-nio-3.8.0.Final.jar!/:3.8.0.Final] │ │ at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) ~[xnio-nio-3.8.0.Final.jar!/:3.8.0.Final]

há mais alguma coisa que eu possa fazer para solucionar o problema mais detalhadamente?

Oi @giordyb

Obrigado por seu exemplo de implantação e relatório. Eu examinei o problema hoje e é um problema bastante estranho.
O problema é causado por ter o registro de depuração habilitado. Existe uma classe DispatcherServlet que irá registrar as partes das requisições enviadas através do ShinyProxy. No entanto, isso causa problemas com algumas solicitações com proxy, porque parte dessas solicitações só pode ser lida uma vez. Portanto, o aplicativo Shiny recebeu uma solicitação inválida.

A solução é desativar o registro de depuração para a classe org.springframework.web.servlet.DispatcherServlet seguinte maneira:

logging:
  level:
     root: DEBUG
     org:
        springframework:
           web:
              servlet:
                 DispatcherServlet: INFO

Este será o padrão na próxima versão do ShinyProxy, de forma que essa solução alternativa não seja mais necessária.

Olá @LEDfan ,

obrigado por examinar isso tão prontamente. Eu adicionei a configuração de registro como você sugeriu e agora tudo está funcionando conforme o esperado, então sou um campista feliz.

muito obrigado pela ajuda!

Estou tendo o mesmo problema com kubernetes por trás do NGINX e do Azure Active Directory. As tabelas de dados são exibidas corretamente com 2.3.1, mas não com 2.4.1. Eu tentei compilações com JDK8 e com JDK11.

Removemos todas as configurações de registro de application.yml e definimos o NGINX para executar sessões 'fixas', mas sem sorte até agora.

Postamos uma versão simplificada de nossos registros do pod application.yml e brilhanteproxy na página de suporte da comunidade. https://support.openanalytics.eu/t/datatables-ajax-error-with-shinyproxy-v-2-4-1/1763 .

Olá @smlehman , obrigado por suas informações extras.

Você poderia fornecer um exemplo de aplicativo Shiny (fontes Dockerfile e R) usando DataTables?
Eu tenho um aplicativo, mas não dá problemas na configuração do Kubernetes (usando nginx também). Obrigado!

Olá @LEDfan
Coisa certa. Para lhe dar uma ideia completa, criei um pequeno repositório com todos os arquivos básicos que estamos usando. Também incluí o README no qual estou trabalhando para apoiar as pessoas interessadas em usar o aplicativo, pois pode fornecer um contexto adicional sobre nossa configuração.

https://github.com/smlehman/shinyproxy-debugDT
Entre em contato se houver mais alguma coisa que possa ajudar na solução de problemas.

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