Shinyproxy: [Bug Report] AJAX-Fehler in der neuen Version von ShinyProxy (Version 2.2.0+)

Vielen Dank! Wir können das reproduzieren und arbeiten daran.

@shrektan danke für die Meldung des Problems.
Ein Fix wurde festgeschrieben:
https://github.com/openanalytics/containerproxy/commit/6455abdaed031297baf600f5e71e2242b689d940

Können Sie diesen Entwickler-Build bitte ausprobieren und sehen, ob er das Problem behebt?
https://nexus.openanalytics.eu/nexus/content/repositories/snapshots/eu/openanalytics/shinyproxy/2.2.1-SNAPSHOT/shinyproxy-2.2.1-20190329.093240-2.jar

@fmichielssen Danke für die schnelle Lösung. Ich kann bestätigen, dass sowohl DT als auch fileInput() mit dem Dev-Build gut funktionieren.

Danke für die Bestätigung, @shrektan! Veröffentlicht als Teil von ShinyProxy 2.2.1

Habe gerade eine Neuinstallation mit 2.2.1 durchgeführt und ich @shrektan gemeldet:

Dann erhalte ich in Shinyproxy.log:

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]

Interessant ist, dass dies ein anderes Paket betrifft: ShinyWidgets. Ich habe eine Reihe von Eingaben, die mit insertUI generiert werden, und die Werte in der unten hervorgehobenen Dropdown-Liste werden aus einer Datenbank (dynamisch) gezogen. Wenn lokal ausgeführt wird, läuft alles großartig (und ich bekomme die tatsächlichen Werte). Bei der Bereitstellung auf Shinyproxy erhalte ich NA1, NA2, NA3 ... super seltsam.

Ich sollte erwähnen, dass die Dinge mit 2.1.0 gut funktionierten. Falls dies einen Unterschied macht, verwende ich Shinyproxy hinter nginx mit einem LetsEncrypt-Zertifikat.

@bogdanrau Könnten Sie eine Dummy-Beispiel-App bereitstellen (ähnlich der von @shrektan bereitgestellten), die es uns ermöglicht, schnell zu reproduzieren?

Hey @tverbeke Ich habe mich gefragt, ob wir jetzt 2.2.1 bereitstellen könnten - ist das behoben?

Hallo @dylancis : Das ursprüngliche Problem ist definitiv behoben, wie unsere Tests und @shrektan bestätigen. Für das von @bogdanrau gemeldete

@tverbeke , ich habe gerade die von @shrektan bereitgestellte Beispiel-App erhalte diesen Fehler. Der einzige Unterschied, den ich sehen kann, ist, dass ich .deb als Dienst verwende, anstatt die .jar-Datei zu verwenden. Verwendet jemand die .deb-Datei?

funktioniert hier gut mit 2.2.1 .

funktioniert hier gut mit 2.2.1 .

Und das mit dem Deb-Installer oder der JAR-Datei? Ich habe nur mit der .deb-Datei eine neue VM von Grund auf neu erstellt und hatte aus irgendeinem Grund immer noch die gleichen Probleme.

Was ist die deb-Datei?

@shrektan : Wenn Sie sich die Shinyproxy-Download-Seite (https://www.shinyproxy.io/downloads/) ansehen, können Sie entweder eine plattformunabhängige Datei (.jar) oder eine für Ubuntu spezifische Deb-Datei herunterladen, die Sie installieren mit dpkg. Ich habe mich für die plattformunabhängige Datei entschieden.

Ich bekomme den gleichen Fehler wie @bogdanrau.
Mein Setup: Ich verwende Shinyproxy 2.2.1 (plattformunabhängiges .jar) hinter nginx.
Mir ist aufgefallen, dass dieser Fehler je nach gewählter Authentifizierungsmethode in ShinyProxy auftritt. Wenn ich das Beispiel von @shrektan (

Kann bestätigen, dass ich auch keycloak mit nginx verwende.

Ich habe dieses Problem auch mit Version >2.1.0 (zuletzt bekannt zu funktionieren) sogar 2.2.1 funktioniert bei mir nicht.
Ich betreibe einen dockerisierten Shinyproxy, der das plattformunabhängige JAR hinter einem Traefik-Reverse-Proxy v1.7.12 abruft.
Ich verwende keycloak v6.0.1 für die Authentifizierung/Autorisierung.
Ich musste zu Version 2.1 zurückkehren, um Datentabellen mit aktiviertem Ajax (server=TRUE) sehen zu können, wenn es deaktiviert ist, funktioniert es mit neueren Versionen.

Gibt es Neuigkeiten oder Workarounds für diesen Fehler?

Ich habe genau das gleiche Problem und kann bestätigen, dass das Problem in Kombination mit keycloak auth auftritt .

Ich verwende Shinyproxy-2.3.0.jar in einer dockerisierten Umgebung auf einem Ubuntu 18.04.2 LTS-Computer. Nginx wird als Reverse-Proxy in Kombination mit einem SSL-Zertifikat von letsencrypt verwendet.

Beispiel-Glanz-App:

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)

Der Versuch, das obere Beispiel mit Shinyproxy und keycloak-auth (übrigens auf demselben Server) auszuführen, führt zu dem erwähnten 503 Service Unavailable AJAX-Fehler. Turning server=FALSE behebt diesen Fehler, kommt aber für große Tabellen nicht in Frage.

Exakt die gleiche Maschine (docker,shinyproxy,nginx-Einstellung) mit einfacher Authentifizierung oder ohne Probleme .

das gleiche problem mit billy34
Verwenden Sie in ShinyProxy 2.3.0 DT::renderDataTable immer noch den gleichen Ajax-Fehler 503
Verwenden Sie keycloak v7.0.0 für die Authentifizierung/Autorisierung
aber umgekehrt zu 2.1 wird gut funktionieren

Beispiel-App

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

Ich habe das gleiche von @bogdanrau erwähnte TruncatedResponseException beim Hochladen von Dateien in RStudio, das in einem dockerisierten Shiny Proxy > 2.1 ausgeführt wird (mit einfacher Authentifizierungsmethode). https://github.com/openanalytics/shinyproxy/issues/170

Fügen Sie einfach ein "Ich auch" hinzu. Das Problem liegt beim Keycloak-Autorisierungs-Backend und wird sonst nicht angezeigt. Die Rückkehr zu 2.1 funktioniert wie erwartet.

Auch mit KeyCloak Auth und jeder ShinyProxy-Version > 2.1.0

Bei nginx (ssl aktiviert) und dem Keycloak-Authentifizierungsdienst ist das gleiche Problem aufgetreten. Allerdings zeigt DT auch ohne Keycloak perfekt an.
Siehe Anhang!

Bei nginx (ssl aktiviert) und dem Keycloak-Authentifizierungsdienst ist das gleiche Problem aufgetreten. Allerdings zeigt DT auch ohne Keycloak perfekt an.
Siehe Anhang!

ShinyProxy 2.3.0 jar von glänzendproxy.io

Wir konnten mit Keycloak reproduzieren. Ein Fix wird in der nächsten Version sein.

Wir konnten mit Keycloak reproduzieren. Ein Fix wird in der nächsten Version sein.

Danke fürs Zurückstellen!

Erhalten Sie den gleichen Fehler, ohne irgendeine Art von Authentifizierung. Bei einer POST-Anfrage des Inhaltstyps: multipart/form-data. Irgendeine Ahnung, was der Unterschied zwischen den beiden Versionen ist, dass dieser Fehler kommt. Bitte schlagen Sie eine Lösung vor, falls das Zurücksetzen nicht möglich ist. Übrigens, ich lasse eine Flasche hinter Shinyproxy laufen
Vielen Dank.

@tverbeke könnten Sie freundlicherweise einen Snapshot des <dev> Zweigs mit diesem Problem beheben? vielleicht entdecken frühe Tests etwas anderes, das möglicherweise behoben werden muss, bevor der <stable> Zweig aktualisiert wird.
Danke im Voraus.

@jaysnm der Fix ist im Entwicklungszweig von containerproxy vorhanden.

@tverbeke Es ist bedauerlich, dass die Entwicklung des Containerproxy- Builds fehlgeschlagen ist (siehe Anhang). Ich habe auch einen Entwicklungszweig von Shinyproxy gebaut
Vielen Dank.

@jaysnm Sie müssen im Moment mit Oracle Java kompilieren. Der Konstruktor in der Klasse sun.security.krb5.KrbTgsReq unterscheidet sich zwischen Oracle Java und OpenJDK und wir sind uns dessen bewusst.

Mit der offiziellen Version 2.3.1 funktioniert das bei mir endlich. Zeit, diese Ausgabe Nr. 140 zu schließen?

Danke für das Feedback, @Dusan-Dingarac

Hallo, ich habe das gleiche Problem nach dem Upgrade von ShinyProxy 2.3.1 auf 2.4.1, können wir den Fehler erneut öffnen?

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

auf Shinyproxy
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]

Ich habe das gleiche Problem mit DT ohne ShinyProxy mit Load-Balancing mit traefik als Reverse-Proxy. Vielleicht mit DT und Load Balancing verbunden?
Muss auf meiner Seite nachforschen
Haben Sie dieses Problem gesehen https://github.com/rstudio/DT/issues/849 ?

Ich verwende traefik auch als Load Balancer, aber ich bin zu 2.3.1 zurückgekehrt und es funktioniert gut, mit 2.4.0 und 2.4.1 gibt es diesen Fehler.

Hallo @giordyb

Ich habe gerade den Beispielcode im ersten Beitrag dieser Ausgabe mit ShinyProxy 2.4.1 getestet und das funktioniert bei mir immer noch.
Können Sie die folgenden Informationen teilen:

• der Code der Shiny-App, die Sie verwenden
• die Konfiguration von Traefik
• vielleicht eine docker-compose-Datei, damit ich dein Setup einfach testen kann

Ich brauche mindestens die beiden ersten Stücke, sonst kann ich das Problem nicht reproduzieren.
Vielen Dank

Fügen Sie hier einfach meine zwei Cent hinzu. Um sicherzustellen, dass DT hinter einem Load-Balancer (Traefik) funktioniert, habe ich kürzlich einen einfachen Repo- DT-Load-Balancer basierend auf Docker Swarm erstellt, mit detaillierten Setups... Ich denke, mit ein wenig Aufwand kann man daraus einen reproduzierbaren machen Beispiel für ShinyProxy zu diesem Thema...

@giordyb Ich habe mein Problem mit traefik und Load Balancing gelöst. Ich verwende immer noch traefik 1.7 (1.7.26) und es gibt immer noch ein Problem mit der Stickiness-Konfiguration. Ich habe das Label "traefik.backend.loadbalancer.stickiness" wie dokumentiert verwendet, aber ohne Erfolg. Die Verwendung des veralteten Labels "traefik.backend.loadbalancer.sticky=true" funktioniert. Ich weiß nicht, ob es ein Hinweis für dieses Problem ist, aber wer weiß.

@billy34 danke, ich führe traefik 2.2 aus, ich habe versucht, die Sticky-Sitzung zu aktivieren, aber es hat keinen Unterschied gemacht. Ich werde den Code und die Traefik-Konfiguration in Kürze posten

@LEDfan Ich führe traefik unter Kubernetes (auf einem Multi-Node-Cluster) aus, daher ist es etwas schwierig, unsere Umgebung mit einem Docker-Compose zu replizieren.
Ich konnte eine kleinere Umgebung mit einem einzelnen Kubernetes-Knoten unter Docker (Docker für Mac) erstellen und es werden immer noch Fehler ausgegeben.

Hier ist der Code für die App (es ist nur ein Beispiel, aber es werden auch Fehler ausgegeben):
_edit: siehe den nächsten Beitrag für den Code_

Ich habe diese Version dieser App mit dieser Konfiguration von traefik unter Shinyproxy 2.3.0 getestet und es funktioniert, wenn ich das gleiche auf 2.4.1 versuche, bekomme ich den Fehler

Eine andere Sache, die ich versucht habe, ist, traefik zu umgehen, indem ich direkt an den Shinyproxy-Container portiere, selbst wenn dies der Fall ist, wird der Fehler angezeigt, daher bezweifle ich wirklich, dass es sich um ein traefik-Problem handelt.

@LEDfan

Ich habe noch ein paar Tests gemacht, es sieht so aus, als hätte traefik nichts damit zu tun.

Ich habe ein Repo erstellt, das meine Umgebung repliziert (https://github.com/giordyb/test_shinyproxy.git)

Auf Docker für Mac mit Kubernetes habe ich 2 Bereitstellungen von Shiny-Proxy (2.3.1 und 2.4.1) erstellt, die dieselbe Shiny-R-Container-Anwendung bedienen.
Es ist kein Traefik beteiligt, auf die glänzenden Proxy-Pods wird über einen Kube-Proxy-Port-Forward zugegriffen.

unter 2.3.1 funktioniert die Anfrage an die Datentabelle

unter 2.4.1 schlägt dieselbe Anfrage fehl

und das bekomme ich im Log des Shinyproxy-Containers
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]

Kann ich meinerseits noch etwas tun, um das Problem weiter zu beheben?

Hallo @giordyb

Vielen Dank für Ihre Beispielbereitstellung und Ihren Bericht. Ich habe mich heute mit dem Problem befasst und es ist ein ziemlich seltsames Problem.
Das Problem wird dadurch verursacht, dass die Debugprotokollierung aktiviert ist. Es gibt eine Klasse DispatcherServlet die die Teile der Anfragen protokolliert, die über ShinyProxy gesendet werden. Dies führt jedoch bei einigen Proxy-Anfragen zu Problemen, da ein Teil dieser Anfragen nur einmal gelesen werden kann. Daher hat die Shiny-App eine ungültige Anfrage erhalten.

Die Lösung besteht darin, die Debug-Protokollierung für die Klasse org.springframework.web.servlet.DispatcherServlet wie folgt zu deaktivieren:

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

Dies wird der Standard in der nächsten ShinyProxy-Version sein, sodass dieser Workaround nicht mehr benötigt wird.

Hallo @LEDfan ,

vielen Dank, dass Sie sich das so schnell angeschaut haben. Ich habe die Logging-Konfiguration wie von Ihnen vorgeschlagen hinzugefügt und jetzt funktioniert alles wie erwartet, also bin ich ein glücklicher Camper.

Vielen Dank für Ihre Hilfe!

Ich habe das gleiche Problem mit Kubernetes hinter NGINX und Azure Active Directory. Datentabellen werden mit 2.3.1 korrekt angezeigt, aber nicht mit 2.4.1. Ich habe Builds mit JDK8 und mit JDK11 ausprobiert.

Wir haben die gesamte Logging-Konfiguration aus application.yml und NGINX so eingestellt, dass es 'Sticky'-Sitzungen ausführt, aber bisher kein Glück.

Wir haben eine vereinfachte Version unserer application.yml und Shinyproxy-Pod-Logs auf der Community-Supportseite veröffentlicht. https://support.openanalytics.eu/t/datatables-ajax-error-with-shinyproxy-v-2-4-1/1763 .

Hallo @smlehman , danke für deine zusätzlichen Informationen.

Könnten Sie bitte eine Shiny-Beispielanwendung (Dockerfile- und R-Quellen) mit DataTables bereitstellen?
Ich habe eine App, aber es gibt keine Probleme bei einem Kubernetes-Setup (auch mit nginx). Vielen Dank!

Hallo @LEDfan
Sichere Sache. Um Ihnen ein vollständiges Bild zu geben, habe ich ein kleines Repo mit allen von uns verwendeten Basisdateien erstellt. Ich habe auch die README-Datei beigefügt, an der ich arbeite, um Leute zu unterstützen, die an der Verwendung der Anwendung interessiert sind, da sie zusätzlichen Kontext zu unserem Setup bieten könnten.

https://github.com/smlehman/shinyproxy-debugDT
Lassen Sie mich wissen, wenn es noch etwas gibt, das bei der Fehlerbehebung helfen würde.