dubbo服务踩过的坑

标签：写代码   连接   集群   time   tor   2.x   mem   pac   bug   

事情起因：当时接了个需求，开发过程中需要对工程A新增依赖工程B和工程C。

写代码，噼里啪啦噼里啪啦。。。

本地起了三个dubbo服务，其他服务依赖开发环境服务，非常开森改自己冒烟的bug。

提测！

测试环境，工程A死活起不来，起到一半卡住！没有任何异常！！！然后过了三分钟，抛出zk心跳连接超时，巴拉巴拉。。

2018-11-22 14:38:03,857 INFO  [kafka-coordinator-heartbeat-thread | webull-trade-analyse--center] Marking the coordinator 10.xx.2.xxx:9092 (id: 2147483646 rack: null) dead for group webull-trade-analyse--center (org.apache.kafka.clients.consumer.internals.AbstractCoordinator) (AbstractCoordinator.java:631)

2018-11-22 14:38:12,049 WARN  [localhost-startStop-1-SendThread(10.70.2.173:2181)] Client session timed out, have not heard from server in 41557ms for sessionid 0x36605afb146892d (org.apache.zookeeper.ClientCnxn) (ClientCnxn.java:1108)

2018-11-22 14:39:49,437 INFO  [localhost-startStop-1-EventThread] zookeeper state changed (Disconnected) (org.I0Itec.zkclient.ZkClient) (ZkClient.java:713)

试过的办法：

1、检查测试环境zk集群的ip和端口。正常

2、检查kafka配置。正常

3、把kafka对应consumer干掉再启动。失败

4、重启测试环境卡住的日志最后一个依赖的dubbo服务，再启动。失败

5、一顿其他瞎操作！！！

一顿操作猛如虎，搞到凌晨都没搞定。。

第二天同事提醒是否和内存有关系，然后查看了下，开发环境配置的xms和xmx 2G，测试环境1G。

发现工程B启动的时候放了一大大大堆到内存中。以前没有依赖B的时候，A随便起。

现在GG。后面把测试环境内存加大，重启。完事！！

麻蛋，一开始怎么没有往内存方面想，心想着内存问题，你至少给我抛个OutOfMemory出来吧！！！

dubbo服务踩过的坑

标签：写代码   连接   集群   time   tor   2.x   mem   pac   bug   

原文地址：https://www.cnblogs.com/jylsgup/p/10010580.html