HPESM 9.5x Web Tier - You have been logged out due to session timeout


I am upgrading from 9.41 to 9.52 and I have noticed that with versions 9.51 and 9.52 of the web tier I am getting, "You have been logged out due to session timeout." without any cause. I am able to reproduce this issue in the following environments: 

Database Application Level: 9.52
RTE Application Level: 9.52
Web Tier Application Level: 9.52

Database Application Level: 9.41
RTE Application Level: 9.52
Web Tier Application Level: 9.52 and 9.51

While I am filling out an incident request, performing fill actions, or just simply filling out the form the session will automatically time out.  All of my settings are still the same between both 9.41 web tier and 9.5x web tier. Has anyone else experienced similar issues or have a workaround? 

Update: Found the following message in the Apache Tomcat localhost.2017-07-18.log file. This message corresponds to the exact time that I was logged out. 

18-Jul-2017 10:24:37.654 SEVERE [ajp-nio-8009-exec-4] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [HP Service Manager Web] in context with path [/sm] threw exception
java.lang.RuntimeException: Too many requests in a short period
at com.hp.ov.sm.client.webtier.DoSMitigationFilter.doFilter(DoSMitigationFilter.java:66)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.hp.ov.cwc.web.EncodingFilter.doFilterInternal(EncodingFilter.java:58)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:486)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

Thanks in Advance, 


  • Hello Steven,

    hope you are doing fine.

    Have you set LB?

    1. Open debughttp in SM Server log.

    2. Check session.timeout setting in webtire web.xml. By default, it should be 15 seconds.

    3. Add JSessionID in tomcat access.log. If tomcat doesn’t support that, add headers or at least cookies (which has JSessionID) in the access.log.


            The JSESSIONID cookie is the oldest cookie. It was created when the user first logged into the system. When the user performs their daily operations in SM, additional other cookies are created. When the number of cookies goes beyond the upper limit: 50, this issue will happen.

    also workaround found that could works >

    For the parameter ThreadsPerChild, it is for Apache http sever performance tuning regarding the server workload. The more concurrent threads you make available to handle requests, the more requests your server can process. But be aware that with too many threads, under high load, requests will be handled more slowly and the server will consume more system resources. So suggest to keep current setting to monitor instead of increasing to high number, if works fine then no need to increase. And it is better to check the CPU and memory utilization and see if they are on high load.



  • Hi Carlos, 

    Thanks for the response.

    (1)  The load balancer is set. 
    (2)  The value for the session-timeout setting in the web.xml is set to 15.
    (3)  I am not sure what you mean by the JSessionID in the tomcat access.log.  

    I know this isn't a supported configuration (i.e., RTE 9.52 and Web Tier 9.41), but I also redeployed the 9.41 web tier and was able to create an incident without being logged out. Seems that there is something new in the 9.5x web tier that might be causing this issue. 

  • Are you using HPSM LB or external LB?

    Are you using a web server (ie. apache) in front of your tomcat or any external LB to them?


    Check in HPSM logs for errors related to invalid session. The rootcause can be a problem in your persistent session. I explain: the user is logged in the servlet 13081 and the request is being sent to the servlet 13083. If this happen you will be disconnected immeditially.

  • Verified Answer

    After upgrading from 9.41 to 9.5x there is a new parameter in the web.xml file called "maxRequestPerSecond" and the default value is 50. I changed the default value to 100 and the behavior has stopped. Support states that it's to help prevent 
    DoS attacks.