Our APP to produce on a more serious accident, after many users complained login to see the information of others, after receiving a complaint we started to look for problems, such problems are usually caused by thread-safe, so look for a reason the idea is thread-safe by the idea to investigate.
Business scenario is that, after the user logged in, click a page to view information, this information shows the information of others.
Log in roughly the transaction process is as follows:
//一系列验证
session.setAttribute("id",id); //身份证号放入session
//其他操作View information transaction process is as follows:
session = request.getSession();
if(session != null && session.getAttribute("LoginStatus") == True) {
String id = session.getAttribute("id");
Information info = queryInfo(id);
return info;
} else {
return "not login";
}By adding logs and other methods, we confirm the information is to check the time, out of the session in the ID number to other people, but in the end is when change did not find, as we have been thinking along the thread-safe to find a place like global variables.
It also found a suspicious place, is to have an asynchronous thread, verifies that the user ID, and once again put in the session.
public void updateId(HttpServletRequest request) {
HttpSession session = request.getSession();
String id = validate();
session.setAttribute("id",id);
}This function is in tune played by the transaction log in the main thread pool, it looks like in fact there is not much wrong, but also the old code, long time. And I found a rule, to be seen by others user information, log transactions are triggered using a new device to log, because we added a logic of switching equipment to do the login authentication, so you need to verify SMS, log in two steps the first step faster return, but the process is still asynchronous updates.
So I suspect that is not because Servlet transactions have returned, although asynchronous thread to get the HttpServletRequest, but this request has been invalidated or are multiplexed.
I wrote the following code for verification, stop with the curl call. Http request to return soon, but I will HttpServletRequest passed a thread pool, and so on until after 5s to handle the Request, the result really is a problem
The result was a problem, in most cases new_session are null, but there have been cases is not null, not at this time find their own session.
HttpServletRequest life cycle is, when a http request over the application server parses the message, various parameters into a HttpServletRequest object, and then passed to the Servlet service function, the function call corresponding to the service according to which method doGet / doPost methods, but once the service function calls end, HttpServletRequest life cycle is over, and then after that you continue to use this object, the result is uncertain.
Online encounter such problems many people, I'm specifically looking for servlet specification, which includes a chapter speaking HttpServletRequest life cycle.
Where you can get the following information:
(1) Effective request three cases: the service function, the function doFilter, from the asynchronous thread startAsync
(2) In addition to the three cases, the use request produce undefined results (indeterminate results)
(3) most of the time to achieve servlet container, in order to improve performance, will reuse the request object, but this is not essential in the specification
Which startAsync mentioned that some began servlet 3.0, which is to allow a worker thread can do IO operations or similar obstruction when the thread capable of other things, but it requires asynchronous thread is over, the request will be returned to the client, in essence, it is synchronized, the only parallel. So, we need asynchronous processing Request, you must use your own servlet asynchronous mechanism, but this does not meet our needs, because we are waiting for is to keep the main thread.
Example usage:
If you use this, then the client needs to wait 5s to get results.
I looked tomcat source code and found that it did indeed Request reuse:
Although the cause of the problem is simple, but the consequences are very serious. When you need asynchronous processing of data must be especially careful here if passed Session no problem, but still have to be avoided.