摘要：排查異常日志，發(fā)現(xiàn)沒有該問題存在。測試功能正常，沒有重現(xiàn)線上問題。解決問題原因定位好了，剩下的就是如何解決了。兩個(gè)方案修改線上配置該上實(shí)施難度系數(shù)高，因?yàn)楣臼褂玫慕y(tǒng)一發(fā)布部署平臺(tái)，開發(fā)人員無服務(wù)器操作權(quán)限。

XX系統(tǒng)中，一個(gè)用戶需要維護(hù)的項(xiàng)目數(shù)過多，填寫的任務(wù)數(shù)超多，產(chǎn)生了一次工時(shí)保存中，只有前面一部分的xx數(shù)據(jù)持久化到數(shù)據(jù)庫，后面的數(shù)據(jù)沒有保存。

圖1

首先想到的是否后面部分的數(shù)據(jù)在保存過程中發(fā)生了異常。排查異常日志，發(fā)現(xiàn)沒有該問題存在。

然后增加方法參數(shù)信息日志，數(shù)據(jù)參數(shù)信息。發(fā)現(xiàn)參數(shù)集合size=200，前端發(fā)送集合size=400。判斷問題可以能是因?yàn)榉?wù)器容器環(huán)境(Nginx+Tomcat)導(dǎo)致

在測試環(huán)境模擬線上數(shù)據(jù)。如圖1

在idea中直接啟動(dòng)tomcat，無nginx環(huán)境，如果沒有問題，則可暫時(shí)確定為nginx問題。

然而，在過程中發(fā)現(xiàn)了新的問題。

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);// 測試報(bào)錯(cuò)時(shí)，此處list只有256個(gè)，index為256時(shí)，取第257個(gè)報(bào)錯(cuò)  
}  

@SuppressWarnings("unchecked")  
    private void growCollectionIfNecessary(  
            Collection collection, int index, String name, PropertyDescriptor pd, int nestingLevel) {  
  
  
        if (!this.autoGrowNestedPaths) {  
            return;  
        }  
        int size = collection.size();  
        // 當(dāng)個(gè)數(shù)小于autoGrowCollectionLimit這個(gè)值時(shí)才會(huì)向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));  
                }  
            }  
        }  
    }  

根據(jù)上面的分析找到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 這個(gè)問題和線上的不同，只能算是意外收獲。革命尚未成功，同志仍需努力！?。?！==

經(jīng)過2.2的奮斗，暫時(shí)判定是否為Nginx post請(qǐng)求參數(shù)做了限制。嗯，開搞~ 在開發(fā)環(huán)境配置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;
    }
}

對(duì)于client_max_body_size 100M;，網(wǎng)上都是與文件上傳相關(guān)的。不過都是通過post， request body的方式上傳數(shù)據(jù)，所以通用。

測試~~

功能正常，沒有重現(xiàn)線上問題。 哭死~~~

革命還要繼續(xù)~~

去線上服務(wù)器拉去配置

經(jīng)分析，發(fā)現(xiàn)線上沒有body size的配置，卻有maxParameterCount="1000"。該參數(shù)為限制請(qǐng)求的參數(shù)個(gè)數(shù)，從而變相限制body size。

在開發(fā)環(huán)境配置該參數(shù)，測試，問題重現(xiàn)。

問題原因定位好了，剩下的就是如何解決了。

兩個(gè)方案：

修改線上配置

該上實(shí)施難度系數(shù)高，因?yàn)楣臼褂玫慕y(tǒng)一發(fā)布部署平臺(tái)，開發(fā)人員無服務(wù)器操作權(quán)限。

修改代碼

修改保存邏輯，分片存儲(chǔ)

問題排查，需要先對(duì)整體有個(gè)把握，然后分析影響范圍。不能鉆牛角尖，采用西醫(yī)“頭疼醫(yī)頭”的方式。有可能最后結(jié)果還是要醫(yī)頭，但此時(shí)的醫(yī)頭已經(jīng)是建立在中醫(yī)的辯證主義上，對(duì)癥下藥。