刷脸交易netty常见异常问题

异常问题"/>

刷脸交易netty常见异常问题

1. 内存溢出

对于交易报文比较小是问题不会暴漏，当数据报文大于60k时就会引发内存溢出问题。 对此问题注意ioty.buffer.ByteBuf的正确使用。有时可能在哪用ByteBuf 做了缓存。这个类比较特殊Gc不会自动回收。所以必须手动回收，可以通过以下方法释放。

ioty.util.ReferenceCountUtil.release(byteBuf);

2. 刷脸报文无法接收

对于刷脸签约交易包含图片信息一般为30kb～300kb，可能报文大一些netty 开启HttpServer 在Handler 的ChannleRead0 中接收的报文长度为0，截取报文会发现应答Request Entity too large。 因为在可能在ChannelInitializer初始化通道时设置报文的大小。一般都是65335。 我们可以修改大小。

ChannelPipline pipeline = ch.pipeline();
pipeline.addLast("http-aggregator",  new HttpObjectAggregator(65535*10));

3. 性能压测存在部分报文没有应答

对于这样的问题可能是关闭通道的问题。主要是关闭通道调用的问题。
1.Channel.close() ；
2.hannel.write(ChannelBuffers.EMPTY_BUFFER).addListener(ChannelFutureListener.CLOSE);

使用1.关闭通道在交易tps小时没问题，但是当你并发比较高时，后端系统耗时比较长，每笔交易在排队。如果设置的超时时间到，还没等到应答。调用1的方法就会关闭通道。如果调用2就不会。因为方法1在io线程正在写入时，突然关闭通道导致报文不完整或者没有应答。通过添加监听器。能使报文完整写入。那为啥还有1方法存在呢，因为是业务场景用的不一样。如果是通知类交易高并发下收不收都无所谓。反而性能会更好，如果业务场景要求每笔交易保证实时有效。那只能通过增加监听器了。

4. 数据sm3计算摘要值是最好不要讲getByte(“GBK”)以参数的形式传入，会影响结果。最好定义byte[] 变量之后传入。

5. 当数据报文过大比如是人脸图片信息，请求报文为xml格式需转换为map ，中父类获取标签值比如:此处有90k字符是设定值读入输入流的大小，如果每次没有读取完，会多次读入导致，图片信息被覆盖，最终导致只保留最后一次读入此标签的值。

   SAXHandler ts = new SAxHandler();
   MapXmlSaxHandler hdl = new MapXmlSaxHandler();//自定义转换处理
   ts.setXhandler(hdl);
   SAXParserFactory factory = SAXParserFactroy.newInstance();
   SAXParser paser = factory.newSAXParser();
   parser.parse(new ByteArrayInputStream(xml.getBytes(),SAXHandler));