摘要:排查異常日志,發現沒有該問題存在。測試功能正常,沒有重現線上問題。解決問題原因定位好了,剩下的就是如何解決了。兩個方案修改線上配置該上實施難度系數高,因為公司使用的統一發布部署平臺,開發人員無服務器操作權限。
問題
XX系統中,一個用戶需要維護的項目數過多,填寫的任務數超多,產生了一次工時保存中,只有前面一部分的xx數據持久化到數據庫,后面的數據沒有保存。
圖1
排查過程 1.增加日志,監控參數信息首先想到的是否后面部分的數據在保存過程中發生了異常。排查異常日志,發現沒有該問題存在。
然后增加方法參數信息日志,數據參數信息。發現參數集合size=200,前端發送集合size=400。判斷問題可以能是因為服務器容器環境(Nginx+Tomcat)導致
2.開發環境問題重現 2.1 模擬數據在測試環境模擬線上數據。如圖1
2.2 只配置Tomcat在idea中直接啟動tomcat,無nginx環境,如果沒有問題,則可暫時確定為nginx問題。
然而,在過程中發現了新的問題。
org.springframework.beans.InvalidPropertyException: Invalid property "detail[256]" of bean class [com.suning.asvp.mer.entity.InviteCooperationInfo]: Index of out of bounds in property path "detail[256]"; nested exception is java.lang.IndexOutOfBoundsException: Index: 256, Size: 256 at org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImpl.java:833) ~[spring-beans-3.1.2.RELEASE.jar:3.1.2.RELEASE] at org.springframework.beans.BeanWrapperImpl.getNestedBeanWrapper(BeanWrapperImpl.java:576) ~[spring-beans-3.1.2.RELEASE.jar:3.1.2.RELEASE] at org.springframework.beans.BeanWrapperImpl.getBeanWrapperForPropertyPath(BeanWrapperImpl.java:553) ~[spring-beans-3.1.2.RELEASE.jar:3.1.2.RELEASE] at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:914) ~[spring-beans-3.1.2.RELEASE.jar:3.1.2.RELEASE] at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:76) ~[spring-beans-3.1.2.RELEASE.jar:3.1.2.RELEASE] at org.springframework.validation.DataBinder.applyPropertyValues(DataBinder.java:692) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE] at org.springframework.validation.DataBinder.doBind(DataBinder.java:588) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE] at org.springframework.web.bind.WebDataBinder.doBind(WebDataBinder.java:191) ~[spring-web-3.1.2.RELEASE.jar:3.1.2.RELEASE] at org.springframework.web.bind.ServletRequestDataBinder.bind(ServletRequestDataBinder.java:112) ~[spring-web-3.1.2.RELEASE.jar:3.1.2.RELEASE]
查看BeanWrapperImpl源碼
else if (value instanceof List) { int index = Integer.parseInt(key); List list = (List) value; growCollectionIfNecessary(list, index, indexedPropertyName, pd, i + 1); value = list.get(index);// 測試報錯時,此處list只有256個,index為256時,取第257個報錯 }
@SuppressWarnings("unchecked") private void growCollectionIfNecessary( Collection collection, int index, String name, PropertyDescriptor pd, int nestingLevel) { if (!this.autoGrowNestedPaths) { return; } int size = collection.size(); // 當個數小于autoGrowCollectionLimit這個值時才會向list中添加新元素 if (index >= size && index < this.autoGrowCollectionLimit) { Class elementType = GenericCollectionTypeResolver.getCollectionReturnType(pd.getReadMethod(), nestingLevel); if (elementType != null) { for (int i = collection.size(); i < index + 1; i++) { collection.add(newValue(elementType, name)); } } } }
根據上面的分析找到autoGrowCollectionLimit的定義
public class DataBinder implements PropertyEditorRegistry, TypeConverter { /** Default object name used for binding: "target" */ public static final String DEFAULT_OBJECT_NAME = "target"; /** Default limit for array and collection growing: 256 */ public static final int DEFAULT_AUTO_GROW_COLLECTION_LIMIT = 256; private int autoGrowCollectionLimit = DEFAULT_AUTO_GROW_COLLECTION_LIMIT;
解決方案,是在自己的Controller中加入如下方法
@InitBinder protected void initBinder(WebDataBinder binder) { binder.setAutoGrowNestedPaths(true); binder.setAutoGrowCollectionLimit(1024); }
==BUT 這個問題和線上的不同,只能算是意外收獲。革命尚未成功,同志仍需努力!!!!==
2.3 增加Nginx經過2.2的奮斗,暫時判定是否為Nginx post請求參數做了限制。嗯,開搞~ 在開發環境配置Nginx代理,過程略·····
nginx.conf 如下
upstream xxxxxxx { server 127.0.0.1:8080 weight=10 max_fails=2 fail_timeout=30s ; } server { listen 80; server_name xxxxxxx.com; client_max_body_size 100M; # 配置post size #charset koi8-r; #access_log logs/host.access.log main; location / { #proxy_next_upstream http_500 http_502 http_503 http_504 error timeout invalid_header; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://xxxxxxx; expires 0; } }
對于client_max_body_size 100M;,網上都是與文件上傳相關的。不過都是通過post, request body的方式上傳數據,所以通用。
測試~~
功能正常,沒有重現線上問題。 哭死~~~
革命還要繼續~~
2.4 Tomcat post設置去線上服務器拉去配置
經分析,發現線上沒有body size的配置,卻有maxParameterCount="1000"。該參數為限制請求的參數個數,從而變相限制body size。
在開發環境配置該參數,測試,問題重現。
3. 解決問題原因定位好了,剩下的就是如何解決了。
兩個方案:
修改線上配置
該上實施難度系數高,因為公司使用的統一發布部署平臺,開發人員無服務器操作權限。
修改代碼
修改保存邏輯,分片存儲
總結問題排查,需要先對整體有個把握,然后分析影響范圍。不能鉆牛角尖,采用西醫“頭疼醫頭”的方式。有可能最后結果還是要醫頭,但此時的醫頭已經是建立在中醫的辯證主義上,對癥下藥。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/93808.html
摘要:排查異常日志,發現沒有該問題存在。測試功能正常,沒有重現線上問題。解決問題原因定位好了,剩下的就是如何解決了。兩個方案修改線上配置該上實施難度系數高,因為公司使用的統一發布部署平臺,開發人員無服務器操作權限。 問題 XX系統中,一個用戶需要維護的項目數過多,填寫的任務數超多,產生了一次工時保存中,只有前面一部分的xx數據持久化到數據庫,后面的數據沒有保存。 圖1 showImg(htt...
摘要:排查異常日志,發現沒有該問題存在。測試功能正常,沒有重現線上問題。解決問題原因定位好了,剩下的就是如何解決了。兩個方案修改線上配置該上實施難度系數高,因為公司使用的統一發布部署平臺,開發人員無服務器操作權限。 問題 XX系統中,一個用戶需要維護的項目數過多,填寫的任務數超多,產生了一次工時保存中,只有前面一部分的xx數據持久化到數據庫,后面的數據沒有保存。 圖1 showImg(htt...
摘要:直到有一天你會碰到線上奇奇怪怪的問題,如線程執行一個任務遲遲沒有返回,應用假死。正好這次借助之前的一次生產問題來聊聊如何排查和解決問題。本地模擬上文介紹的是線程相關問題,現在來分析下內存的問題。盡可能的減少多線程競爭鎖。 showImg(https://segmentfault.com/img/remote/1460000015568421?w=2048&h=1150); 前言 之前或...
摘要:直接顯示了一個疑似內存泄漏的問題。然后分析文件給出的信息,發現一個叫的類。文件里面說的內存泄漏的大概的意思就是說,這個類里面的存放的東西太多了,爆掉了。修改了代碼將調用的地方改成了單例。修改完線上跑了一段日子,后來也沒有出現過這樣的問題。 問題描述: ????早上去公司上班,突然就郵件一直報警,接口報異常,然后去查服務器的運行情況,發現java的cpu爆了.接著就開始排查問題 問題解決...
閱讀 1824·2021-09-28 09:46
閱讀 3143·2019-08-30 14:22
閱讀 1878·2019-08-26 13:36
閱讀 3343·2019-08-26 11:32
閱讀 2081·2019-08-23 16:56
閱讀 1151·2019-08-23 16:09
閱讀 1303·2019-08-23 12:55
閱讀 2148·2019-08-23 11:44