异常问题"/>
刷脸交易netty常见异常问题
- 内存溢出
对于交易报文比较小是问题不会暴漏,当数据报文大于60k时就会引发内存溢出问题。 对此问题注意ioty.buffer.ByteBuf的正确使用。有时可能在哪用ByteBuf 做了缓存。这个类比较特殊Gc不会自动回收。所以必须手动回收,可以通过以下方法释放。
ioty.util.ReferenceCountUtil.release(byteBuf);
- 刷脸报文无法接收
对于刷脸签约交易包含图片信息一般为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));
- 性能压测存在部分报文没有应答
对于这样的问题可能是关闭通道的问题。主要是关闭通道调用的问题。
1.Channel.close()
;
2.hannel.write(ChannelBuffers.EMPTY_BUFFER).addListener(ChannelFutureListener.CLOSE);
使用1.关闭通道在交易tps小时没问题,但是当你并发比较高时,后端系统耗时比较长,每笔交易在排队。如果设置的超时时间到,还没等到应答。调用1的方法就会关闭通道。如果调用2就不会。因为方法1在io线程正在写入时,突然关闭通道导致报文不完整或者没有应答。通过添加监听器。能使报文完整写入。那为啥还有1方法存在呢,因为是业务场景用的不一样。如果是通知类交易高并发下收不收都无所谓。反而性能会更好,如果业务场景要求每笔交易保证实时有效。那只能通过增加监听器了。
-
数据sm3计算摘要值是最好不要讲getByte(“GBK”)以参数的形式传入,会影响结果。最好定义byte[] 变量之后传入。
-
当数据报文过大比如是人脸图片信息,请求报文为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));
更多推荐
刷脸交易netty常见异常问题
发布评论