Push() and Weblogic problem

Vaadin 6 / 7 / 8
1

Hi,

My applivation uses Vaadin 7.1 and is running in WebLogic Server 10.3.6.0. I am using Vaadin Push() with 10s timer so that one of my views is updating every 10s. The application and weblogic em-console froze after a couple of hour and there is following errors in log:

STUCK] ExecuteThread: ‘14’ for queue: ‘weblogic.kernel.Default (self-tuning)’ has been busy for “628” seconds working on the request "Workmanager: default, Version: 0, Scheduled=true, Started=true, Started time: 628141 ms [ GET /trukki/PUSH/?v-uiId=5&v-csrfToken=d9419d19-c129-4bde-bffe-bde5b6f3b7c0&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=1.0.13&X-Atmosphere-Transport=streaming&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application/json;%20charset=UTF-8&_=1383554622224 HTTP/1.1 Connection: keep-alive User-Agent: Mozilla/5.0 (Linux; Android 4.0.4; FieldBook_E1 Build/IMM76L) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Safari/535.19 Content-Type: application/json; charset=UTF-8 Accept: / Referer: http://owlprodb.host.uki-lan.net:7001/trukki/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: JSESSIONID=LnwyS3bHnrv1CWPJlmXnjwCCvDSlTZCBxXq628sYWbvR4m8SfmyZ!-2003407996 ]
", which is more than the configured time (StuckThreadMaxTime) of “600” seconds. Stack trace: java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:167) org.mortbay.util.ajax.WaitingContinuation.suspend(WaitingContinuation.java:72) org.atmosphere.container.JettyCometSupport.service(JettyCometSupport.java:105) org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1448) com.vaadin.server.communication.PushRequestHandler.handleRequest(PushRequestHandler.java:109) com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1329) com.vaadin.server.VaadinServlet.service(VaadinServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:820) weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301) weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119) java.security.AccessController.doPrivileged(AccessController.java:284) oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315) oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442) oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103) oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171) oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71) weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:139) weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730) weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696) weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273) weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179) weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490) weblogic.work.ExecuteThread.execute(ExecuteThread.java:256) weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

I dont know what causes this error so if someone knows something about this please help me.

Forgot to add my code:

private void startUpdateTimer(){
	getRefreshDelay();
    timer = new Timer();
    timer.scheduleAtFixedRate(new TimerTask() {
        @Override
        public void run() {
            try {
                getUI().access(new Runnable() {
                    @Override
                    public void run() {
                    	if(getUI().iterator().hasNext()){
                    		if(getUI().iterator().next().getId().equalsIgnoreCase(TrukkiNavigationParameter.TILAUSJAKELUVIEW)){
                    			TilausjakeluView tv = (TilausjakeluView)getUI().iterator().next();
                    			tv.setCurrentTablePage();
                    			tv.updateContent();
                    			getUI().push();
                    		}
                    	}
                    }
                });
            } catch (final UIDetachedException e) {
            	detach();
            }
        }
    }, 0, refreshDelay);
}
2

Apparently WebLogic kills request threads that are “stuck” handling a single request for longer than StuckThreadMaxTime. This plays poorly with the way HTTP streaming works (the fallback push mechanism used if WebSocket is not supported, as is the case with WebLogic).

What streaming does is to keep a single request open “indefinitely”, incrementally writing to the response to push data back to the client. In your case, this entails each client reserving an entire thread for potentially long periods of time - something that’s not very efficient. The async functionality in Servlet 3.0 would make things more scalable, but WebLogic 10 doesnt’ support that, either.

I think in your use case it would be better just to use polling (UI.setPollInterval) - it’s simpler and more reliable.

BTW, you might like to use getUI().getContent() instead of get().iterator().[has]
next() :slight_smile:

3

I only found following poll example:

https://vaadin.com/wiki/-/wiki/Main/Using%20polling

Can someone tell if there is better example for my case.

I am asking this because now I have one UI class and separeted View classes. So is there a way to update table conten in one view without push() (using just polling)

4

We have the same problem in our application with vaadin 7.1.4 and weblogic 10.3.4 ( 11g ). We tested the quick tickets application using push and also has the same problem if it is deployed on weblogic :

<08-nov-2013 10H45’ CET> <[STUCK]
ExecuteThread: ‘1’ for queue: ‘weblogic.kernel.Default (self-tuning)’ has been busy for “165” seconds working on the request "weblogic.servlet.internal.ServletRequestImpl@b5d156[
GET /quicktickets-dashboard-1.0.1/PUSH/?v-uiId=0&v-csrfToken=755692f8-4006-41e1-9423-7a66316de42d&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=1.0.14.vaadin4&X-Atmosphere-Transport=streaming&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application/json;%20charset=UTF-8&_=1383903779806 HTTP/1.1
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Content-Type: application/json; charset=UTF-8
Accept: /
Referer: http://localhost:7001/quicktickets-dashboard-1.0.1/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: es-ES,es;q=0.8
Cookie: JSESSIONID=p7PQS8yD2Bbyr2s5nJSQdmQtjgn2k2TGFZ4pj9YLszmg4vWgtqZB!-1290940566

]", which is more than the configured time (StuckThreadMaxTime) of “600” seconds. Stack trace:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:485)
org.mortbay.util.ajax.WaitingContinuation.suspend(WaitingContinuation.java:72)
org.atmosphere.container.JettyCometSupport.service(JettyCometSupport.java:105)
org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1448)
com.vaadin.server.communication.PushRequestHandler.handleRequest(PushRequestHandler.java:109)
com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1371)
com.vaadin.server.VaadinServlet.service(VaadinServlet.java:238)
javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3717)
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
weblogic.work.ExecuteThread.run(ExecuteThread.java:176)

These threads leave the server in warning state and finally the service degrades. We tried to configure the push long polling, but simply transport parameters enables WEBSOCKETS or STREAMING.
We can see in traces of weblogic that only the first query is performed by STREAMING, then the remaining requests are made by POLLING. Just is the streaming request that gives this problem.

According your comment can not be configured in weblogic 11g Vaadin PUSH?

Obviously if we remove the @Push and configure the UI with setPollInterval solve the problem but we haven’t a push system and increased the number of server requests.

I tried to apply the solution comented at atmosphere forum (https://github.com/Atmosphere/atmosphere/wiki/Enabling-Native-Support-for-WebLogic-11x-and-lower), but I don’t know how to change the atmosphere servlet, this could be work?

Thank you.

5

Long polling is currently not supported by Vaadin due to bugs; it should be available in 7.2. It should be noted, though, that changing from streaming to long polling only helps in cases the server regularly pushes updates, so that any given request only waits for a shorter time than the timeout.

I’ll experiment a bit - I think it might be possible to resume the streaming request after each push, in practice emulating long polling.