In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/01 Report--
This article mainly introduces the relevant knowledge of "how to solve the deserialization problem encountered when using Spring Session to manage distributed sessions." Xiaobian shows you the operation process through actual cases. The operation method is simple and fast, and practical. I hope this article "how to solve the deserialization problem encountered when using Spring Session to manage distributed sessions" can help you solve the problem.
problem arises
We ran into a hidden problem while using SpringSession (which we didn't realize was relevant when the problem arose). As usual, after the user successfully logs in, the user's entity class information is instantiated and saved to the session, and the session is finally saved to redis. This process is actually no problem.
As the business iterates over time, the user entity needs to add additional fields for the updated requirements, so we naturally add other String attributes to the class. As a result, we find that we cannot enter the login page. From the browser console, we find that this request keeps reporting 302 because we cannot obtain the correct authentication, and the browser error home page prompts us to "clear browser cookies". When we do, The login page magically opened up and we were able to log in and use the system smoothly. When we went back to the server to check the background log, we saw that there was a deserialization problem in redis, and the log report was very strange, not a log directly thrown by a line of our business code, which gave us a little trouble in locating the problem.
analyze problems
First there is a problem with deserialization. The first thing we can think of is adding extra attributes to the user entity, but why is there a problem with deserialization? The reason seems very simple. Our user entity class does implement the Serializable interface, but we do not write the serialized serialVersionUID shown. This will definitely fail to deserialize after the entity changes the attribute field, because when you do not specify the serial number serialVersionUID number, the system defaults to automatically generate the class name class attribute, etc. The serialization value obtained by different attribute names must be different. The solution is very simple. That is, when initializing the class, actively write the serialVersionUID number.
But our program is now in production, and we can't do this because it's obviously inconsistent to generate sequence numbers according to the new class. Add a transient field to the new field? This practice is also walking, which means that the value of this field will not be serialized, and other systems will definitely not use it later. These extra fields have no meaning to exist.
After analyzing the error log line by line, it was found that this exception was actually related to SpringSession.
Because we used request.getSession () after the user successfully logged in to the system. setAttribute ("xx", "xx") operation, we put our user entity into the session, and successfully put it into Redis by SpringSession, and our session duration is 48 hours; After our new entity update came in, as soon as the system was released, the login page was opened and the system initialized the contents in SpringSession. It was found that the user entity could not be initialized back from Redis because the serialization numbers before and after were not aligned, so it reported that the deserialization failed crazily. This is the fundamental problem.
solve problems
So how do we solve it? Obviously, smart browsers gave us the first solution, which was to clear the browser Session.
Because we mentioned above, SpringSession will automatically set a cookie value named SESSION in the browser. This value is for the background service to find the previously stored Session in Redis so as to identify the unified user. When the browser clears the Cookie, the SESSION value is lost, so the system regenerates the SESSION value for the user who initiated the request for this browser. This request cannot find the corresponding Session in redis. There is no deserialization of the user entity, the login process can certainly proceed normally, and the subsequent interaction is normal.
Then there is another solution, from the Redis side, since SpringSession will use this SESSION to find the corresponding value in Redis, then we will clear the Session content stored in this Redis. If the content is not found, there is no need to deserialize it. However, at this time, the normal access user will also consider it as a session expiration forced exit because the request does not find a unified Session. Here, the way to clear the contents in redis can use the following command:
$ redis-cli keys '*' | xargs redis-cli del
$ redis-cli del spring:session:sessions:7e8383a4-082c-4ffe-a4bc-c40fd3363c5e
The third way is to transform from the code side. The essence of deserialization failure is that the original class adds new attributes, and the class does not display the specified serialVersionUID. Then we can adapt it and keep the original class unchanged. The new attributes are placed in a class that inherits the user entity class. Later, we will use this new class to keep the old class unchanged (attribute type and number are unchanged). Yes, that is, the way to use the new class, the new class inherits the user entity class, keeps the user entity class unchanged, adds the attribute field that needs to be supplemented, and needs to be serialized, so that SpringSession can still find the original class without flexibility when it is initialized. We can also implement our new requirements well.
The content of "How to solve the deserialization problem encountered when using Spring Session to manage distributed sessions" is introduced here. Thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the industry information channel. Xiaobian will update different knowledge points for you every day.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.