我解决过的问题列表8.2

未解决：
7
问题时间：2014-11-28
优先级：@
问题：Proactor模式下10000个下位机同时上传电表数据模拟实现
原因：配置不能快速配置成脚本，Proactor模式未能实现
总结：
解决时间：
历时：

6
问题时间：2014-11-28
优先级：@
问题：不能用多个下位机同时发送数据
原因：设计Acceptor模式，UDP广播，配置扩展，配置ConfigLoader不再保存map，调用communicate的add接口来加载信息，Proactor模式下socket连接有效性的判断，粘包问题处理
总结：
解决时间：
历时：
已废弃
5.1
问题时间：2014-11-28
优先级：@@@
问题：将系统做成Windows下的服务，启动另外一个monitor监控程序，并启动日志
原因：不再使用，有问题应该跨平台，有问题应该改BUG第一位，monitor只是调试试运行阶段的缓兵之计，不可依赖。
总结：不是所有问题都应该被解决
解决时间：2014-12-11
历时：23

4
问题时间：2014-11-28
优先级：@
问题：core文件分析，现场有core文件
原因：程序存在BUG，目前还没有能力很好的分析core文件，找出问题所在，目前Windows下VS开发调试比较方便，还没有必要在Linux下开发的必要。
总结：总结：不是所有问题都应该被解决
解决时间：2014-12-11
历时：23

已解决：
6
问题时间：2015-02-05
问题：机器人绘图程序，在界面上选择点时，能将这些点用线连接成一条线
原因：原来的算法比较简单，无法应对复杂情况
解决方法：使用最小生成树的方法尝试去解决，发现会分叉，所以应该类似贪吃蛇的方法；和女朋友讨论之后最终确定应是两头蛇的方法，用一个双端队列，新被考虑的点，离哪个头近就加入到哪一头变成新的蛇头。
附图：左侧为解决之前的问题，连线效果比较差，右侧为新算法的效果



总结：自己在算法方面的积累得到了发挥，很有信心。
解决时间：2015-02-06
5
问题时间：2014-11-28
优先级：@@@@
问题：大楼采集对端连接丢失之后，本地会陷入连接异常而不能恢复
原因：socket失效未加以判断就使用，现在增加了失效的判断作为返回值，如果失效则关闭socket，从头开始
[cpp] view plaincopyprint?
ssize_t bytes_received = peer.recv(buffer,MAX_ASDU_LENGTH);
if (bytes_received == -1)
{
ACE_DEBUG((LM_DEBUG,”socket not exist\n”));
peer.close();
sock_closed = true;

总结：UDP由于是无连接的所以不涉及这类问题，但是TCP作为面向连接的，双方或者网络时刻都可能让连接断掉，所以检查连接的有效性就贯穿了整个通信过程。是基本常态。
解决时间：2014-12-11
历时：23天（中间很多事情耽搁，同事又被拉到其他项目组做设计）

8
问题时间：2014-12-1
优先级：@@@@
问题：有一台远程机器连接不了本地Linux上的Mysql数据库
原因：本地root用户登录不了Mysql，提示con’t connect …./var/lib/mysql/mysql.sock,查找到/tmp/mysql.sock之后做了ln -s软连接；又出现Access denied for user root@localhost,此时直接输入mysqll可以直接进入MySQL数据库命令行。后来因为修改了grant，导致所有连接都无法连接本地数据库，就直接修改root的密码，全都搞定。
注：解决过程详述：
具体原因是：原来连接不上的机器A在远程修改了要连接的B机器上的Mysql连接信息，导致B机器上的mysql.user表中专门针对A的IP有一个root的其他密码。
解决方法：（1）删除针user表中针对A的IP的那条root记录，（2）按照上文的方法，修改root的密码，所有远程连接都可以使用统一的root账户的新密码连接了（这里新密码和老密码一样，目的是为了清除A所在IP那条不正常记录）
总结：同注
解决时间：2014-12-2
历时：2天

3
问题：用tcp和对端通信是，如果断网，本地程序会陷入socket不可用的循环而不能恢复到初始状态从新开始
原因：socket异常断开之后，本地程序在使用socket对象之前应该检查socket的可用性。
总结：UDP无连接，封装一个发送一个接收即可满足大部分要求。TCP的连接整个过程都是双方维护的socket的状态上通信，TCP的连接状态是用TCP通信的基本常识。
2
问题：现场环境一直会重连数据库，导致写数据库失败之后写本地文件，猜测会导致数据大量丢失
原因：实际数据并没有丢失，而是数据库里面的表加了索引（这个索引是必须要的，减少了垃圾数据的产生），我总是尝试插入和索引冲突的重复数据，所以导致写文件。
总结：没有到现场gdb调试或者把core文件拷贝回来调试是发现问题慢的一个原因；对大量日志用Linux命令分析的能力不足，需要更多的Linux分析和开发命令来帮助自己在最短的时间内找到日志线索。
历时：7天
1
问题：生成的插件不能与其他插件兼容
原因：自己修改了类定义，添加了一个成员变量，使用了这个成员变量，但是没有和其他插件统一编译，而且我使用的对象是由其它的插件生成的，所以运行时找不到这个成员变量。就会一直core dump
总结：对一个由多个插件组成的项目，应该有版本控制，统一发布；不会在Linux下用gdb调试使得这个问题发现到解决整整用了两天时间，完全是猜测；在什么环境下开发就应该熟练掌握这个环境下的调试！对于有多个项目的，考虑使用CMake生成跨平台的项目代码。
历时：2天