使用Postman发送请求时一直sending request

使用Postman发送请求时一直sending request

1. 问题

   今天是年后上班的第二天，打开idea想试一下年前已经上线的接口，测试的时候使用的是postman测试，在测试一个简单的查询接口时Postman一直卡在sending request，并且后端也没有任何报错信息，请求地址、携带数据也没有问题，因此很疑惑。

2. 代码

   1）Controller层接口代码

   @PostMapping("/selectList")
   @OperLog(operModule = "图标资源管理", operDesc = "图标资源列表查询" , operType = SysLogConstants.OPERATION_SELECT)
   public CommonResult selectList(@RequestBody IconRequest iconRequest){
       if(iconRequest.getPageNum() == null || iconRequest.getPageSize() == null){
           //默认分页
           iconRequest.setPageNum(0);
           iconRequest.setPageSize(10);
       }
       CommonPage<IconResponse> page = iconService.selectList(iconRequest);
       return CommonResult.success(page,"查询成功");
   }
   复制代码

   其中@OperLog是同事们写的自定义注解，是用来记录操作的注解

3. 自己的解决思路

   1）首先自己的想法便是先检查在使用Postman时路径地址、参数格式以及字段是否与Controller层匹配，测试的token是否过期，请求类型是否正确。

   2）在确定Postman编写的内容没有问题后我在return的前一行打了断点，并以debug模式执行，结果发现page中携带有从数据库中查询到的数据，但Postman中依然是显示sending request。

   3）既然该接口不能测试通过，那么就尝试其它接口是否能够正常运行。在此我尝试了两个接口，分别是updateIconStatus和findBannersAll，其中updateIconStatus接口格式与上面的查询方法类似，findBannersAll如下：

   @PostMapping("/findBannersAll")
   public CommonResult findBannersAll(@RequestBody NewBannersDto newBannersDto) {
       return CommonResult.success(newBannerService.findBannersAll(newBannersDto));
   }
   复制代码

   使用Postman对这两个接口进行测试，测试的结果为updateIconStatus和selectList接口一样Postman一直在sending request，而findBannersAll接口能够查询到数据。

   4）不同的接口测试结果不一样，因此我在Controller层写了一个测试接口：

   @GetMapping("/test")
   public String test(){
       return "测试";
   }
   复制代码

   结果是测试通过，在此时我发现测试通过的接口好像都没有使用@OperLog注解，因此我尝试将selectList接口上的@OperLog注释掉，然后使用Postman测试后在Postman中获取到了正确的返回数据。

4. 问题的定位

   1）我将上面@OperLog注解的问题和同事聊了一下，然后一起去寻找答案。我寻找的方向是自定义注解失效一般与上面有关，然后就在网上查询相关的解决方法，但还是没有找到较好的，自己很多也看不懂。同事则在数据库的操作日志中发现了一个问题，那就是我们的操作日志最晚的一条的时间是年前，但是今天即使测试成功的接口也没有相对应的操作记录。同时因为@OperLog需要将日志写入到数据库中，那必然有插入到数据库的代码块，经过对自定义注解的测试，发现就是这个插入日志的动作失效。

5. 实际原因与解决

   虽然我们两个找到了是@OperLog注解中插入动作失效的问题，但是还是没有较好的解决方法，后来有一位经验较为丰富的同事解决了这个问题，解决方法是释放数据库服务器上的部分磁盘空间。然后我去网上查询了相关的解答，发现磁盘满后mysql会出现以下的状况：

   1）每分钟检查一次是否有空闲空间，并且10分钟写一次错误日志

   2）因为磁盘满了，所有binlog无法更新，redolog也无法更新，所有buffer pool中的数据无法被flush上，如果不幸的服务器重启，或者实例被kill了，那必然会造成数据丢失，这几乎是一定的。所以，处理磁盘满的问题最好是先释放出来一定空间让dirty数据刷新下来。

   3）磁盘满了会导致操作挂起

   3.1）经过网上的解答和实际的测试发现select操作不会因为磁盘满而无法执行，因此select操作在磁盘满时也能正常执行。

   3.2）insert操作在磁盘满时会卡住

   因此导致使用Postman发送请求是一直sending request的一种可能是磁盘满了，解决的方法可以是释放一定的磁盘空间。