最近接手了一个关于数据质量的项目，是一个很老项目了，一直没有新的需求，但因为还有很多用户在使用，所以一直处于运维中。
这个项目平常不会出问题，但出了问题就是让人头疼的问题。
最近收到用户这样的一个反馈，说是在给某个报警分组添加成员时，保存失败，甚至在页面上把错误打印了出去（非常不友好的体验，任何页面的错误都应当是业务性质的，即，用户可以读懂，而非专业性的异常信息），如下图所示：
这是基本的表单保存功能，仅仅是将分组名称、分组描述、分组用户插入到mysql表中，功能比较简单。但是在点击【保存】按钮后，抛出了异常（下面绿色部分的SQL异常）。
从上述的异常信息可以得知，name这个参数没有传过去值，或者说保存的时候值是null。
调查方向
1. 前端使用ajax提交表单，可能是前端没有传递这个参数或表单提交不对，经过调查可排除，截图如下：
2. 后台Spring在进行参数绑定的时候出错，因为两个自定义的bean中都包含name属性，可能Spring绑定时错误，但这点在本地进行测试的时候，也排除了，虽然两个自定义的bean中都包含name属性，但Spring并没有偏私，两个bean中的name属性都被赋值了，如下图：
3. 经过以上两点可知，在进入保存方法时，方法参数就是为null，事实证明，确实为null，但不知道是前端传过来的时候就是null，还是Spring解析参数的时候，对参数的value有长度限制
继续调查
4. 使用谷歌页面调试，发现页面发起的请求中，参数的value都有，但是某个隐藏域的logText的参数的value值在保存到文档后查看，其大小有2.07MB
5. 既然前端在传递参数的时候，没有丢失参数的情况发生，（各个表单属性都有值，也间接说明post请求时，大小是没有限制的）那么可以确定，在服务器端丢失的参数值。
6. 查阅文档及谷歌、百度了一遍也没有发现Spring对参数的绑定会因为参数过大而丢失数据的情况，所以最后定位在了tomcat容器，会不会是tomcat容器接收不了这么大的数据
7. 查看tomcat的server.xml文件，配置如下（类似，但非线上配置）：
- <Connector port="8080" protocol="HTTP/1.1"
- connectionTimeout="2000"
- redirectPort="8443"
- URIEncoding="UTF-8"
- maxThreads="3000"
- compression="on" compressableMimeType="text/html,text/xml" />
果然没有设置post请求的限制，所以tomcat使用默认限制：2MB，也就是说，对与超过2MB的请求，参数不做处理，可以理解为丢弃该参数值。
8. 既然已经定位到问题，解决起来就好办了，将tomcat的server.xml文件进行修改，如下：
- <Connector port="8080" protocol="HTTP/1.1"
- connectionTimeout="2000"
- redirectPort="8443"
- URIEncoding="UTF-8"
- maxThreads="3000"
- compression="on" compressableMimeType="text/html,text/xml"
- maxPostSize="0"/> // 表示对post请求没有限制
注：
如果post没有请求大小的限制恐怕有点不太现实，所以，线上我将maxPostSize的大小设置了10MB，这个基本能满足很多需求了。
maxPostSize是Byte单位的，如果要设置10M，则应当设置为maxPostSize=“10485760”
综上，问题得以解决
