Application restart unexpectedly

Hi,

I am currently putting an Vaadin Application in a production environment. The users are very happy with the UI and with the usage of an “Application” on the web.

There are only two “show-stopper” issues related with Vaadin:
[b]

  1. OutOfSync Message
    [/b]
    [b]
  2. Application suddenly restarts without warning
    [/b]
    It’s not related with session timeout, because it happens in the middle of consecutive UI events.

What can cause this?
(This issues are not replicable / systematic)

Environment:
Vaadin version: 6.4.8
Browser: Chrome
App Server: Glassfish v3

Thanks in advance.

I haven’t really heard of anything similar with other applications using (stock) Vaadin. Problems like that usually refer to bugs in the client side or some really wonky API usage.

Some questions:

  1. Do you have any Vaadin add-ons in use from the directory?
  2. Have you modified some client side code of Vaadin?
  3. Is it some common sequence that the user does when the out of sync happens or is it absolutely random?
  4. Does it leave some mark in the server logs? (It should)

Hello Jens,

OutOfSync problem solved (I think). Update UI from another thread without syncronize.

  1. Yes. Blackboard, among others not used on that screen (Refresher, JFreeChartWrapper, TreeTable, AppletIntegration, ContextMenu and LazyQueryContainer)
  2. No.
  3. My bad… update UI from another thread without syncronize. Fixed.

About application restart:

  • When the application restarts i see nothing on server log.
  • I am trying to confirm that this happen during the usage of the Groovy ScripEngine to eval an expression. I’m suspecting about this eval usage.

Thanks

Hi,

Still with problem “Application restart unexpectedly”…

More info:
I have a Web Application Listener configured… interface HttpSessionListener.
On server log nothing happens… only the System.err.println(“session destroyed…”); message appears…

Thanks

I really have no idea what could cause it, as I haven’t heard of something similar from any other application.

If I understood correctly, the code System.err.println() is run every time this happens? If you know where the code is run from, can you put a breakpoint at that point? You would get a stack trace in debug mode when it happens and you could trace back what called the restart originally.

Hi Jens,

Yes the SessionListener.sessionDestroyed method runs every time this happens.

Now, i’m printing the stack trace on SessionListener.sessionDestroyed.

StackTraceElement[] stackTraceElements =  Thread.currentThread().getStackTrace();
if (stackTraceElements != null) {
      for (int i = 1; i < stackTraceElements.length; i++) {
          StackTraceElement ste = stackTraceElements[i]
;
          String classname = ste.getClassName();
          String methodName = ste.getMethodName();
          String fileName = ste.getFileName();
          int lineNumber = ste.getLineNumber();
          System.err.println("\t" + classname + "." + methodName + "(" + fileName + ":" + lineNumber + ")");
      }
}


StackTrace of an unexpected application restart:

[#|2010-12-22T17:05:06.513+0000|	myApp.servlet.listeners.SessionListener.sessionDestroyed(SessionListener.java:28)|#]

[#|2010-12-22T17:05:06.513+0000|	org.apache.catalina.session.StandardSession.expire(StandardSession.java:743)|#]

[#|2010-12-22T17:05:06.513+0000|	org.apache.catalina.session.StandardSession.expire(StandardSession.java:705)|#]

[#|2010-12-22T17:05:06.513+0000|	org.apache.catalina.session.StandardSession.expire(StandardSession.java:693)|#]

[#|2010-12-22T17:05:06.513+0000|	org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1378)|#]

[#|2010-12-22T17:05:06.513+0000|	org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:206)|#]

[#|2010-12-22T17:05:06.513+0000|	myApp.portal.AraPortal.logout(AraPortal.java:952)|#]

[#|2010-12-22T17:05:06.514+0000|	myApp.portal.AraPortal$3.windowClose(AraPortal.java:215)|#]

[#|2010-12-22T17:05:06.514+0000|	sun.reflect.GeneratedMethodAccessor271.invoke(null:-1)|#]

[#|2010-12-22T17:05:06.514+0000|	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)|#]

[#|2010-12-22T17:05:06.514+0000|	java.lang.reflect.Method.invoke(Method.java:597)|#]

[#|2010-12-22T17:05:06.514+0000|	com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:487)|#]

[#|2010-12-22T17:05:06.514+0000|	com.vaadin.event.EventRouter.fireEvent(EventRouter.java:161)|#]

[#|2010-12-22T17:05:06.514+0000|	com.vaadin.ui.AbstractComponent.fireEvent(AbstractComponent.java:1154)|#]

[#|2010-12-22T17:05:06.515+0000|	com.vaadin.ui.Window.fireClose(Window.java:1318)|#]

[#|2010-12-22T17:05:06.515+0000|	com.vaadin.ui.Window.close(Window.java:1127)|#]

[#|2010-12-22T17:05:06.515+0000|	com.vaadin.ui.Window.changeVariables(Window.java:1095)|#]

[#|2010-12-22T17:05:06.515+0000|	com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1094)|#]

[#|2010-12-22T17:05:06.515+0000|	com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:590)|#]

[#|2010-12-22T17:05:06.515+0000|	com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:266)|#]

[#|2010-12-22T17:05:06.515+0000|	com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:476)|#]

[#|2010-12-22T17:05:06.515+0000|	javax.servlet.http.HttpServlet.service(HttpServlet.java:847)|#]

[#|2010-12-22T17:05:06.516+0000|	org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)|#]

[#|2010-12-22T17:05:06.516+0000|	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)|#]

[#|2010-12-22T17:05:06.516+0000|	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)|#]

[#|2010-12-22T17:05:06.516+0000|	org.jasig.cas.client.util.HttpServletRequestWrapperFilter.doFilter(HttpServletRequestWrapperFilter.java:62)|#]

[#|2010-12-22T17:05:06.516+0000|	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)|#]

[#|2010-12-22T17:05:06.516+0000|	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)|#]

[#|2010-12-22T17:05:06.516+0000|	org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:167)|#]

[#|2010-12-22T17:05:06.516+0000|	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)|#]

[#|2010-12-22T17:05:06.517+0000|	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)|#]

[#|2010-12-22T17:05:06.517+0000|	org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(AuthenticationFilter.java:93)|#]

[#|2010-12-22T17:05:06.517+0000|	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)|#]

[#|2010-12-22T17:05:06.517+0000|	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)|#]

[#|2010-12-22T17:05:06.517+0000|	org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)|#]

[#|2010-12-22T17:05:06.517+0000|	org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)|#]

[#|2010-12-22T17:05:06.517+0000|	org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)|#]

[#|2010-12-22T17:05:06.517+0000|	com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)|#]

[#|2010-12-22T17:05:06.518+0000|	com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)|#]

[#|2010-12-22T17:05:06.518+0000|	org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)|#]

[#|2010-12-22T17:05:06.518+0000|	org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)|#]

[#|2010-12-22T17:05:06.518+0000|	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)|#]

[#|2010-12-22T17:05:06.518+0000|	com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)|#]

[#|2010-12-22T17:05:06.518+0000|	com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)|#]

[#|2010-12-22T17:05:06.518+0000|	com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)|#]

[#|2010-12-22T17:05:06.518+0000|	com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)|#]

[#|2010-12-22T17:05:06.519+0000|	com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)|#]

[#|2010-12-22T17:05:06.519+0000|	com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)|#]

[#|2010-12-22T17:05:06.519+0000|	com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)|#]

[#|2010-12-22T17:05:06.519+0000|	com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)|#]

[#|2010-12-22T17:05:06.519+0000|	com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)|#]

[#|2010-12-22T17:05:06.519+0000|	com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)|#]

[#|2010-12-22T17:05:06.519+0000|	com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)|#]

[#|2010-12-22T17:05:06.519+0000|	com.sun.grizzly.ContextTask.run(ContextTask.java:69)|#]

[#|2010-12-22T17:05:06.520+0000|	com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)|#]

[#|2010-12-22T17:05:06.520+0000|	com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)|#]

[#|2010-12-22T17:05:06.520+0000|	java.lang.Thread.run(Thread.java:619)|#]

Thanks

As I see it, the interesting part here is

I had different line numbers in my Vaadin version than yours so I had to guess a little, but I bet it is this code that is being run inside of Window.changeVariables():

if (isClosable()) {
    // Closing
    final Boolean close = (Boolean) variables.get("close");
    if (close != null && close.booleanValue()) {
        close();
    }
}

The javadoc says that isClosable() only affects subwindows and not the main window, but it seems that this isn’t true. changeVariables is the method that accepts all the actions that happens on the client side and modifies the server side. For some reason the client side is telling the main window to close itself. Only places that I can come to think of where something like this would happen is when the user actually closes the browser window, or when the url of the current page is changed (either by user or by the application).

Maybe someone smarter than me could pitch in?

Hi Jens,

Thanks for your help.
You are right, the code that runs on Window.changeVariables() is exactly this:

I’m sure that this happens without close browser. I’m sure too that the url is not changing neither by user nor by the application. And I’m sure too that the browser refresh (F5) is not being called.

Thanks

Hello,

As a workaround, currently i will deploy the application with the setClosable(false) on the main window.
Which means that main window will not be closed when the browser is closed… This will keep the session alive on server…

I have no idea what can cause this…