In the new release version (2.3.0) of ShinyProxy, all the Apps that use DT with server processing mode will break. The browser complains Ajax errors while browsers programmer tool says "jquery.min.js:4 POST http://myip/app_direct/retire/session/cbc7bf01da3a023b6db378384c240836/dataobj/shiny_table?w=&nonce=22377961e7fd2317 503 (Service Unavailable)"
alert box as bellowings:
myip 顯示
DataTables warning: table id = DataTables_Table_0 - Ajax error. For more information about this error, please see http://datatables.net/tn/7
like https://github.com/openanalytics/shinyproxy/issues/140
my enviornment:
OS: Ubuntu Ubuntu 18.04.3 LTS
authentication: keycloak 7.0.0
ReverseProxy: Nginx
Example-shiny-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)
Exact the same machine (docker,shinyproxy,nginx setting) with simple auth or ldap in application.yml is running without any trouble.
shinyproxy.log as belowings:
2019-08-28 11:46:21.991 INFO 14337 --- [XNIO-2 task-3] e.o.containerproxy.service.UserService : User logged in [user: test1]
2019-08-28 11:46:25.142 INFO 14337 --- [XNIO-2 task-6] c.s.docker.client.DefaultDockerClient : Starting container with Id: f24f391a707d19228f5e97da1e7f8e271230760e91bee2898f454b0bddd0f15a
2019-08-28 11:46:28.068 INFO 14337 --- [XNIO-2 task-6] e.o.containerproxy.service.ProxyService : Proxy activated [user: test1] [spec: retire] [id: 4199b4a8-60dd-43e7-ad8e-0bfac025cc76]
2019-08-28 11:46:28.828 ERROR 14337 --- [XNIO-2 I/O-3] io.undertow.proxy : UT005028: Proxy request to /proxy_endpoint/4199b4a8-60dd-43e7-ad8e-0bfac025cc76/session/4fba467e8b4976c85ad4be80ee538d7d/dataobj/shiny_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.3.jar!/:0.8.3]
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]
Thanks for the report! This is indeed a duplicate of #140
thanks, wait for bug fix
Any update on this bug?
I has been fixed in the mean time. We are preparing for release.
@tverbeke Can you please share the commit or PR? We really need this, tried some hacks, unable to resolve it properly.
Could you point to the commit or the branch you have been working on, That would be very helpful. @tverbeke
@tverbeke any update? It would be very helpful.
This is the relevant commit: https://github.com/openanalytics/containerproxy/commit/c99298934470b2ecee35c9eb9ad67e49fc7acd46
https://github.com/openanalytics/shinyproxy/issues/184 Not sure how it solves this. It can be replicated without Keyclock authentication when authentication is set to none.
Any update on this bug?
Thank you for being proactive and reminding about the issue, however it seems less productive to post similar comments in multiple issues, particularly in this one, which was closed as duplicate...
https://github.com/openanalytics/shinyproxy/issues/184 Not sure how it solves this. It can be replicated without Keyclock authentication when authentication is set to none.
Indeed #184 seems to be a different issue, for which this fix might not help. However the comment is related to the _current issue_ (and #140) which mentions the use of keycloak auth.
Sorry for the multiple comments. My idea was that since the origin of the issue is a POST request, which is failing with the same error. They might have a similar kind of solution.
Looking forward to the solution of #184 ☺️
Hi, I get this error again. I downgraded from 2.4.1 to 2.3.1 and the error disappeared.
@KZARCA A fix by @LEDfan will be in the next release.
Most helpful comment
I has been fixed in the mean time. We are preparing for release.