Today, I encountered a setting timeout problem in the project. The application.properties changes of SpringBoot2 never took effect.
The embedded container used by Spring Boot is controlled by the server.* properties. Spring Boot will create an instance of the servlet container using one of the ServletWebServerFactory instances. These classes use server.* attributes to configure managed servlet containers (such as Tomcat, Jetty, etc.).
When the application is packaged into a war file and deployed to a Tomcat instance, the server.* attributes cannot be used. These do not apply as the prefabricated servlet container can be leveraged (since the service is running remotely). Therefore, deploying to a remote Tomcat will render the server.* properties useless.
server: servlet: session: timeout: PT1H # 1小时过期 cookie: max-age: PT1H # 1小时过期
Note: PT1H means that the time to set the session expiration is 1 hour.
Extension: Duration
The setTimeouot method is found by viewing the springboot source code. Here, the instance of Duration is required to be passed in.
public void setTimeout(Duration timeout) { this.timeout = timeout; }
Duration is new in Java8 and is mainly used for calculation Date difference, Duration is declared final and is thread-safe.
If you convert a string, it is similar to the date formatting method of SimpleDateFormat
Duration. Strings are similar to numbers, which are positive and negative: the default is positive, and negative starts with '-', followed by Then 'PT', the following time letters:
'D' - day
'H' - hour
'M' - Minutes
'S' - Seconds
Each unit must start with a number, and hours and minutes The order of seconds cannot be messed up, for example: PT2H3M2S is equal to -PT-2H-3M-2S.
1) In the conf directory of tomcat, change servler.xml:
<Context path="/abtest" docBase="/abtest" defaultSessionTimeOut="3600" isWARExpanded="true" isWARValidated="false" isInvokerEnabled="true" isWorkDirPersistent="false"/>
2) Change web.xml in the project:
<session-config> <session-timeout>20</session-timeout> </session-config>
3) Change in the program
session.setMaxInactiveInterval(30*60);
When you encounter the same problem, please read the red words above and troubleshoot in order.
Test code:
@RestController @RequestMapping("/valid-time") public class TestController { @GetMapping("/test") public String validTime(HttpServletRequest request, HttpServletResponse response) { HttpSession session = request.getSession(); int sessionTime = session.getMaxInactiveInterval(); return new StringBuilder("sessionTime=").append(sessionTime).toString(); } }
The huge pit that causes Spring session failure due to out-of-synchronization of Linux server time
Due to business needs, the original stand-alone environment was converted into a cluster environment. In order not to modify the tasks, spring session redis was chosen as the session sharing solution.
After confirming the technical solution, I searched a lot of information about spring session on the Internet. After reading it and not finding any pitfalls of previous people, I started to work on it.
The redis installation process is ignored.
Add spring session to the project step by step according to the information. The single-node project ran successfully without any errors, and the session was successfully written to redis.
Then for the sake of safety, I installed nginx on my computer and deployed 3 tomcats. Everything looked perfect, and session sharing was completed between multiple nodes.
So far, all the preliminary preparations have been completed, and the last step is just left.
The nightmare begins...
Deploy all nodes online, and then open the browser to successfully access the application. Of course, we can't just stop at the point where we see the page is completed, we have to do it no matter what. Log in and log in, so...
Then...
I entered the user password countless times, prompting that the login was successful, but the final result was still being rejected, o(╥﹏╥)o
The next step is to fill in countless pitfalls
Look at the logs...
Look at various request requests...
I suspect there is a BUG in the spring session... …
Even turned on the remote DEBUG mode debugging, and finally saw in the universal DEBUG mode that when the spring session getsSession, if the session is obtained, will first determine whether the session has expired, compare The method is also very simple, which is to obtain the current system time and compare it with the expiration time of the session. If the current time is less than the expiration time, it indicates that the session has not expired. Seeing this, I instantly felt a sense of enlightenment, and the small universe finally broke out here.
Nima—>All the acquired sessions were expired, and then...then...of course I hurriedly ran to check the server time, so...I cried o(╥﹏╥)o, it turned out to be Nima It was you who tricked me...
In order to commemorate this journey of lying in the trap, I am posting this article
date command:
date : View the current time, the results are as follows: Tue Mar 4 01:36:45 CST 2017
date -s 09:38:40 :Set the current time, the result is as follows: Tue Mar 4 09:38:40 CST 2017
ntpdate command:
ntpdate -u ntp.api.bz :Network time Synchronization command
ntp commonly used server:
China National Time Service Center: 210.72.145.44
NTP server (Shanghai): ntp.api.bz
The above is the detailed content of How to solve the problem that the Springboot2 session timeout setting is invalid. For more information, please follow other related articles on the PHP Chinese website!