0
votes

Background - I am refactoring some legacy code into the spring web-mvc framework.

I am using Spring 5.0.5.RELEASE and tomcat 8.5.31.

I am launching the application through eclipse Oxygen.3a Release (4.7.3a) and on Fedora 28.

Problem - When starting up tomcat, the application dispatcher intermittently (about 75% of the time) re-launches. It seems that after the application loads, and I get a finished message, and reloads.

After completing the second application loading, everything seems to work normally.

In production, since I have a few timer tasks that get created at startup, these tend to get duplicated. Thus I have duplicate timer task threads running, which is a problem.

—————————————FIRST LAUNCH EXAMPLE

05-Jul-2018 20:45:29.207 INFO [Thread-17] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["http-nio-8080"]

05-Jul-2018 20:45:29.209 INFO [Thread-17] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["ajp-nio-8009"]

05-Jul-2018 20:45:29.211 INFO [Thread-17] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["http-nio-8080"]

05-Jul-2018 20:45:29.212 INFO [Thread-17] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["ajp-nio-8009"]

05-Jul-2018 20:45:29.931 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version: Apache Tomcat/8.5.31

05-Jul-2018 20:45:29.933 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Apr 27 2018 20:24:25 UTC

05-Jul-2018 20:45:29.934 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number: 8.5.31.0

05-Jul-2018 20:45:29.934 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux

05-Jul-2018 20:45:29.934 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 4.16.15-300.fc28.x86_64

05-Jul-2018 20:45:29.934 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64

05-Jul-2018 20:45:29.934 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-4.b10.fc28.x86_64/jre

05-Jul-2018 20:45:29.935 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 1.8.0_171-b10

05-Jul-2018 20:45:29.935 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation

05-Jul-2018 20:45:29.936 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /opt/apache-tomcat-8.5.31

05-Jul-2018 20:45:29.936 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /opt/apache-tomcat-8.5.31

05-Jul-2018 20:45:29.936 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties

05-Jul-2018 20:45:29.937 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

05-Jul-2018 20:45:29.937 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.awt.headless=true

05-Jul-2018 20:45:29.938 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.security.egd=file:/dev/./urandom

05-Jul-2018 20:45:29.938 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048

05-Jul-2018 20:45:29.939 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources

05-Jul-2018 20:45:29.939 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027

05-Jul-2018 20:45:29.939 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xms512M

05-Jul-2018 20:45:29.939 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx2048M

05-Jul-2018 20:45:29.940 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:+UseParallelGC

05-Jul-2018 20:45:29.940 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dignore.endorsed.dirs=

05-Jul-2018 20:45:29.941 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/opt/tomcat

05-Jul-2018 20:45:29.941 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/opt/tomcat

05-Jul-2018 20:45:29.941 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/opt/tomcat/temp

05-Jul-2018 20:45:29.941 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: [/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]

05-Jul-2018 20:45:30.042 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]

05-Jul-2018 20:45:30.053 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read

05-Jul-2018 20:45:30.061 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-8009"]

05-Jul-2018 20:45:30.063 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read

05-Jul-2018 20:45:30.064 INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 592 ms

05-Jul-2018 20:45:30.088 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]

05-Jul-2018 20:45:30.088 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/8.5.31

05-Jul-2018 20:45:32.224 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.

2018-07-05 20:45:32 INFO o.s.w.s.DispatcherServlet:494 - FrameworkServlet 'dispatcher': initialization started

2018-07-05 20:45:32 INFO o.s.w.c.s.XmlWebApplicationContext:590 - Refreshing WebApplicationContext for namespace 'dispatcher-servlet': startup date [Thu Jul 05 20:45:32 UTC 2018]; root of context hierarchy

2018-07-05 20:45:32 INFO o.s.b.f.x.XmlBeanDefinitionReader:316 - Loading XML bean definitions from ServletContext resource [/WEB-INF/dispatcher-servlet.xml]

(There is more here but just wanted to show to the TLD and dispatcher initialization......)

———————SECOND LAUNCH EXAMPLE

(The first launch finishes with the spring URL mapping messages...)

2018-07-05 20:28:34 INFO o.s.w.s.m.m.a.RequestMappingHandlerMapping:547 - Mapped "{[/manualArtifact],methods=[GET]}" onto public java.lang.String com.deorc.controller.ViewManualController.manualArtifact(javax.servlet.http.HttpServletRequest,org.springframework.ui.Model)

2018-07-05 20:28:34 INFO o.s.w.s.m.m.a.RequestMappingHandlerMapping:547 - Mapped "{[/manualBonuses],methods=[GET]}" onto public java.lang.String com.deorc.controller.ViewManualController.manualBonuses(javax.servlet.http.HttpServletRequest,org.springframework.ui.Model)

2018-07-05 20:28:35 INFO o.s.w.s.m.m.a.RequestMappingHandlerAdapter:574 - Looking for @ControllerAdvice: WebApplicationContext for namespace 'dispatcher-servlet': startup date [Thu Jul 05 20:28:27 UTC 2018]; root of context hierarchy

2018-07-05 20:28:35 INFO o.s.w.s.m.m.a.RequestMappingHandlerAdapter:574 - Looking for @ControllerAdvice: WebApplicationContext for namespace 'dispatcher-servlet': startup date [Thu Jul 05 20:28:27 UTC 2018]; root of context hierarchy

2018-07-05 20:28:35 INFO o.s.w.s.h.SimpleUrlHandlerMapping:373 - Mapped URL path [/resources/**] onto handler 'org.springframework.web.servlet.resource.ResourceHttpRequestHandler#0'

2018-07-05 20:28:35 INFO o.s.w.s.DispatcherServlet:509 - FrameworkServlet 'dispatcher': initialization completed in 7348 ms

05-Jul-2018 20:28:37.167 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.

2018-07-05 20:28:37 INFO o.s.w.s.DispatcherServlet:494 - FrameworkServlet 'dispatcher': initialization started

2018-07-05 20:28:37 INFO o.s.w.c.s.XmlWebApplicationContext:590 - Refreshing WebApplicationContext for namespace 'dispatcher-servlet': startup date [Thu Jul 05 20:28:37 UTC 2018]; root of context hierarchy

2018-07-05 20:28:37 INFO o.s.b.f.x.XmlBeanDefinitionReader:316 - Loading XML bean definitions from ServletContext resource [/WEB-INF/dispatcher-servlet.xml]

——————————————————

NOTE: I don’t know why I am getting two controller advice info logs giving me the start up date for the ‘dispatcher-servlet’. And I am not sure if this is the issue.

The only logged item between initialization competed and started is an info message from Tomcat about the TLD scanner. This would seem to indicate the start of the second launch. The same TLD message exists prior to the first initialization. Thus, I do not think it is an issue. I tried turning off the TLD scan w/o success.

Any suggestions or recommendations would be greatly appreciated.

2

2 Answers

0
votes

I was finally able to fix the problem. Though, I do not understand exactly why this occurred. The problem was how I defined my servlet within the web.xml.

Previously, I had:

  <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>/WEB-INF/dispatcher-servlet.xml</param-value>
    </init-param>
    <load-on-startup>10</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
  </servlet-mapping>

Which has now been changed to:

   <servlet>
    <servlet-name>dark-expanse-dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>dark-expanse-dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
  </servlet-mapping>

1) The <load-on-startup> tag was definitely causing a re-initialization.

2) Providing a specific parameter for the contextConfigLocation also seems to have caused the same issue.

3) Lastly, and I am not sure about this one, I change the servlet name from the default of "dispatcher" to a application specific name along with the dispatcher-servlet.xml file. It is possible that the spring uses dispatcher as well.

0
votes

I probably should have posted sooner since this was resolved last summer. The problem was not Spring but the Tomcat configuration. The issue is that Tomcat has a known bug within the server.xml as it relates to the context tag. Check the tomcat documentation with regards to the context tag usage for more details.