失败,开始重连.错误代码为iVMS-4200.EXE[302]？

Posted 2023-05-16

只有一个是这个样子

iVMS-4200.exe[302]的错误码：

【问题原因】

监控点不可用或者不存在。可能是设备网络中断导致设备掉线。

解决的步骤如下：

1、确认下该监控点的网络状态是否正常，一般是由于设备掉线导致的图像预览不了。

2、若都是正常的，按照下面的步骤设置即可。

3、设置完毕后，就可以看到远程的视频了。

注意：海康威视的通道分模拟和网络两种，模拟的通道号从1到32，网络的通道号从33到64，换算一下，如果网络摄像头接到1号网口上，则通道号为33。

资料拓展：

录像机常见故障
问题1：当使用网络端时，不能监看，如何处理？

首先要明白使用网络端监看需要满足几个条件，网络端设置是否设置好了，网络是否畅通？如通过路由器上网软件需要的21个端口是否映射到主控端上？是否有个固定的IP或者域名？如果是局域网监看，那么只要保证设置好了，保证网络畅通(如果网络不畅通呢，检查一下线路)和主控端开着就可以监看。如果是广域网监看，除了网络端需要设置好，在看看主机能否上网？如果上不了。看看网关和DNS设置是否正确（其中网关和DNS应该是路由器的IP）？然后看看路由器是否能把端口映射到监控主机上？其中固定的IP或者域名是必不可少的。只要几个条件都符合了，监看是没有问题的。

问题2：机器反复自动重起

此现象是因为用户进行了一些非正常操作，累积效应致使Windows系统死机，而监控主机有死机保护功能，即重新启动Windows系统；另外机器放置环境通风条件不好使机箱或CPU风扇损坏而导致散热不充分，引起监控主机死机。解决建议：卸载软件，然后重新安装监控软件；改善通风条件，更换损坏风扇。

问题3：软件启动立即报告错误

此错误出现的概率极低，在一台管理正常的主机上不会出现。一般地，产生此故障的原因如下：1)用户主机经常性地突然断电； 2)多次在一台硬件配置极不稳定的机器上运行本软件。解决建议：检查主机配置，重新启动软件。 参考技术A 失败,开始重连.错误代码为iVMS-4200.EXE[302]。如果出现这样的情况，你可以试着重启一下。 参考技术B 失败,开始重连.错误代码为iVMS-4200.EXE[302]，连不上网，链接失败，要解决网络问题。 参考技术C 没有遇到类似你这样的情况，实在是对你的问题有心无力。 参考技术D 或者不存在。可能是设备网络中断导致设备掉线。 解决的

ZOOKEEPER重连失败BUG踩坑记

问题提出

问题第一次被发现是有业务反馈Staging环境新添加的定时任务无法按时调度，通过第一时间查看日志，我们发现错误日志都是和ZOOKEEPER断连相关，且持续在增长。

分析过程

接下来通过一些常规的检查，没有什么特别发现，尝试复现也没有成功，因为与ZK断开重连这个功能平时也是测试比较充分的。从日志看到，持续了10多分钟发现与ZK的会话连接仍然没有成功，这时候我们就想，难道只能祭出重启大法了么？

突然间想到，ZK客户端机制就是不断尝试重连，如果客户端没有异常，有没可能是ZK服务端的问题？查看服务端的日志，发现以前没有见过的错误信息“Len error 1733124”，感觉离胜利又近了一步。

通过搜索ZOOKEEPER源码，发现了这个错误的触发条件。当数据包大小超过了maxBuffer（默认1MB）限制就会导致抛出这个异常。

并未有非法操作，为什么会出现重连失败情况？会不会是组件的BUG? Google搜索Len error果然找到ZOOKEEPER issue.  https://issues.apache.org/jira/browse/ZOOKEEPER-706

考虑到生产环境ZK断开并不罕见，而且数据远远不止1MB，为什么没出现该问题？

通过查找资料和阅读源码找到了原因，ZOOKEEPER客户与服务端的重连并非超时后再尝试重连，而是在心跳断开2/3会话时长后会尝试连接另一个服务器，此时旧的sessionId未过期，客户端会将一次性打包所有的watch发送到服务端，如果全部watch拼接的path大小超过了服务器设置的参数jute.maxbuffer值(默认大小为1M)时，服务器将拒绝连接，而客户端则会一直重试，导致重连不成功。至此，终于真像大白。

One important parameter you should set when creating a session is the session timeout, which is the amount of time the ZOOKEEPER service allows a session before declaring it expired. If the service does not see messages associated to a given session during time T, it declares the session expired. On the client side, if it has heard nothing from the server at 1/3 of T, it sends a heartbeat message to the server. At 2/3 of T, the ZOOKEEPER client starts looking for a different server, and it has another 1/3 of t to find one.

解决方案

通过在测试环境构造条件复现后，最后通过设置服务端参数-Djute.maxbuffer为合适的大小这种workaround的方式来解决该问题。当然还有更彻底的方法也就是升级ZOOKEEPER组件至3.4.8以上的版本。

由于基础架构不止一个产品使用ZOOKEEPER组件，后来也将该问题分享给其它产品团队，至于分享过后引发了另一场血案就是另一个故事了。