Shinyproxy: [Bug Report] AJAX error 503 (Service Unavailable) in ShinyProxy (version 2.3.0)

Created on 28 Aug 2019  ·  13Comments  ·  Source: openanalytics/shinyproxy

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]

Most helpful comment

I has been fixed in the mean time. We are preparing for release.

All 13 comments

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.

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.

Was this page helpful?
0 / 5 - 0 ratings