|
锁定老帖子 主题：阿里巴巴Dubbo分布式服务框架已开源
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-02-28
web.xml配置：
<context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:/client.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> 启动后，consumer没有注册成功！ 但是我的测试用例却可以成功注册，且调用service都没有任何问题。检查了好几遍，jar包也没有发现重复或不同版本的现象。
protected static String[] config = { "classpath:/client.xml" };
protected Logger log = Logger.getLogger(getClass());
public ApplicationContext ctx;
@Before
public void setUp() throws Exception {
ctx = new FileSystemXmlApplicationContext(config);
}
@Test
public void test() {
DemoService ds = (DemoService) ctx.getBean("demoService");
for (int i = 0; i < Integer.MAX_VALUE; i++) {
log.info(ds.sayHello(" dubbo very good! "));
}
}
谢谢！ |
| 返回顶楼 | |
|
发表时间：2012-02-28
dubbo通过把服务器列表引到客户端实现负载均衡器压力的客户端分担，那么通过什么即时机制实现客户端能觉察服务端心跳（可正常使用）呢？
|
| 返回顶楼 | |
|
发表时间：2012-02-28
最后修改：2012-02-28
Letsgo 写道 启动后，consumer没有注册成功！
但是我的测试用例却可以成功注册，且调用service都没有任何问题。检查了好几遍，jar包也没有发现重复或不同版本的现象。 consumer的reference是lazy的，如果引用没有被注入到其它Bean或直接getBean，是不会初始化的。 如果需要饥饿初始化，可以配置： <dubbo:reference ... init="true" /> 或者： <dubbo:consumer ... init="true" /> |
| 返回顶楼 | |
|
发表时间：2012-02-28
最后修改：2012-02-28
aaa_star 写道 dubbo通过把服务器列表引到客户端实现负载均衡器压力的客户端分担，那么通过什么即时机制实现客户端能觉察服务端心跳（可正常使用）呢？
Dubbo的Remoting层有心跳机制，定时检测网络的最后一次读写时间，如果一直有数据来回表示连接是好的，如果很长时间没有读写，就发一个心跳包过去，如果不能响应，就重建连接。 在负载均衡时，每个提供者的Invoker都有isAvailable()状态，优先选可用的提供者进行调用。 参见：AbstractClusterInvoker.java 的doselect()方法。 |
| 返回顶楼 | |
|
发表时间：2012-02-28
javatar 写道 Letsgo 写道 启动后，consumer没有注册成功！
但是我的测试用例却可以成功注册，且调用service都没有任何问题。检查了好几遍，jar包也没有发现重复或不同版本的现象。 consumer的reference是lazy的，如果引用没有被注入到其它Bean或直接getBean，是不会初始化的。 如果需要饥饿初始化，可以配置： <dubbo:reference ... init="true" /> 或者： <dubbo:consumer ... init="true" /> 哇，非常感谢，一语点醒我这傻蛋啊，我貌似，好像在文档里看过，就是没想起来。感谢梁飞的即时回复。 |
| 返回顶楼 | |
|
发表时间：2012-02-28
为什么我的simple-monitor 启动后，无法发现新的服务，新增的service 和 consumer 要重启 simple-monitor 才可以看到。。。
谢谢！ |
| 返回顶楼 | |
|
发表时间：2012-02-28
javatar 写道 ximenpiaohua 写道 看了一下源代码，收获还是很大，值得研究，目前研究了一下服务器端代理的创建，以及代理的调用过程，写的还是蛮清晰的，不知道楼主能否发些文档出来研究起来方便一点，另外关于mina产生大锯齿的垃圾回收的原因能否解析一下。
内部培训的PPT，我们正在做整理后，后续也会发出来。 关于Mina产生大锯齿的垃圾回收的原因： 通过jmap分析内存，发现存在大量的ConcurrentBlockingQueue$Node对象，跟踪代码初步判断是，Mina严格遵守selector收到write事件后，再触发从队列中取出信息进行发送，而Netty做了短路，发现IO空闲，不经过队列直接发送，在大压力测试下，Mina队列中的数据因停留，被移到old区了，从而导致full-gc的发生，在小压力下，都没有问题。 哎，这个问题我之前也研究过， 不知道是不是和你说的一个内容， 请看从System.gc()=》 查找引用==> java.nio.Bits.reserveMemory()==>java.nio.DirectByteBuffer 构造器==> java.nio.ByteBuffer的 public static ByteBuffer allocateDirect(int capacity) { return new DirectByteBuffer(capacity); } mina在接收/发送 缓存达大于1KB（mina的默认缓冲值）的时候就会发生 allocateDirect 重新分配，而这个过程会导致显示的调用System.gc()，后来我们把系统jvm系统参数加上 -XX:+DisableExplicitGC 代码显示GC最终才得以解决。 |
| 返回顶楼 | |
|
发表时间：2012-02-29
BruceXX 写道 javatar 写道 ximenpiaohua 写道 看了一下源代码，收获还是很大，值得研究，目前研究了一下服务器端代理的创建，以及代理的调用过程，写的还是蛮清晰的，不知道楼主能否发些文档出来研究起来方便一点，另外关于mina产生大锯齿的垃圾回收的原因能否解析一下。
内部培训的PPT，我们正在做整理后，后续也会发出来。 关于Mina产生大锯齿的垃圾回收的原因： 通过jmap分析内存，发现存在大量的ConcurrentBlockingQueue$Node对象，跟踪代码初步判断是，Mina严格遵守selector收到write事件后，再触发从队列中取出信息进行发送，而Netty做了短路，发现IO空闲，不经过队列直接发送，在大压力测试下，Mina队列中的数据因停留，被移到old区了，从而导致full-gc的发生，在小压力下，都没有问题。 哎，这个问题我之前也研究过， 不知道是不是和你说的一个内容， 请看从System.gc()=》 查找引用==> java.nio.Bits.reserveMemory()==>java.nio.DirectByteBuffer 构造器==> java.nio.ByteBuffer的 public static ByteBuffer allocateDirect(int capacity) { return new DirectByteBuffer(capacity); } mina在接收/发送 缓存达大于1KB（mina的默认缓冲值）的时候就会发生 allocateDirect 重新分配，而这个过程会导致显示的调用System.gc()，后来我们把系统jvm系统参数加上 -XX:+DisableExplicitGC 代码显示GC最终才得以解决。 这是因为DirectMemory需要gc才能释放，但Dubbo之前是在没有用DirectMemory时也出现锯齿。 |
| 返回顶楼 | |
|
发表时间：2012-03-02
Home > Services > com.pica.service.AuthorityService > Providers | Consumers | Statistics | Charts >
为什么服务跑了几天，请求不断，却没有charts 信息？有谁遇到过？ |
| 返回顶楼 | |
|
发表时间：2012-03-02
遇到一个奇怪的问题，我在某机房部署一套 Service ,然后注册中心 使用 zookeeper，监控simple-monitor 都在同一台服务器上，当servic服务启动后，我发现dubbo://ip:20880 这个ip居然与服务IP不一样，什么情况？？？ |
| 返回顶楼 | |
