服务端不可用的时候的并发问题 about jupiter HOT 10 CLOSED

你好，是允许并可以重复订阅的，select 方法里面调用的 client.awaitConnections 是同步阻塞方法，没有通知的概念
订阅服务并建立连接是回调的通知机制，但也有对应的处理以避免重复建立连接，具体参考 watchConnections 里的 notify 方法

from jupiter.

@fengjiachun 感谢回复，应该是我理解的有问题。感谢！

from jupiter.

@fengjiachun 您好！ 我对昨天提的问题进行了测试
测试步骤如下：
1.启动本地注册中心JupiterRegistryServer
2.启动客户端AutoJupiterClient，没有等待连接可用，直接发起100个请求，请求超时时间20秒（此时服务端并未启动）
3.启动服务端
4.关闭服务端

出现情况如下，同一个客户端订阅了100次同一个服务，等待服务端启动后，同一客户端收到了100次服务上线通知。关闭服务端后，同一客户端收到了100次服务下线通知。
这个情况是否合理？还是我操作有问题？如果发生在实际生产环境，是否会因为某一服务完全不可用造成一些问题。

from jupiter.

Hi 没太明白你的意思哈，你指的通知100次是哪个通知 void onAvailable(Runnable listener) 的 listener 还是 NotifyListener 这个？100 个订阅者分别都要收到通知不是应该的么？ 所以你的问题现在是这个现象导致多创建了什么资源还是？

from jupiter.

是NotifyListener，我并没有创建100个订阅者，而是使用1个客户端并发100个请求的，结果订阅了100次同一个服务。我将请求的超时时间设置为20秒，并发发送100个请求，但是其实这个时候是没有任何服务可用的（没有启动服务端），在20秒的超时时间内，我启动了服务端，之后就产生了这样的现象。

from jupiter.

                                if (group.isConnecting()) {
                                    group.onAvailable(() -> onSucceed(group, signalNeeded.getAndSet(false)));
                                } else {
                                    group.setConnecting(true);

NotifyListener 实现的 isConnecting 判断就是避免你这种并发情况去创建过多链接，既然没有创建多余的链接，似乎你说的这个也不是什么问题？

from jupiter.

每个 watchConnections 都会产生一个订阅者，产生多少个最终就要通知多少个，没什么问题，或者你认为有什么问题？

from jupiter.

@fengjiachun 感谢回复。可能是我理解的有点问题哈。不过我还是想问一下
那么在服务不可用的时候，每一次请求都会产生一个订阅者？（是否会膨胀造成客户端内存溢出，好像也不会被GC回收掉？）。我理解的是同一个客户端重复订阅一个服务，是否只需要一个订阅者就可以了？

from jupiter.

我理解的是同一个客户端重复订阅一个服务，是否只需要一个订阅者就可以了？

不同订阅者，在被 notify 可能需要做的事情也不一样，这就跟消息系统里面多个消费组一样
本质上这里就是要做成广播，几个 listener 对象理论上对 gc 没什么影响

from jupiter.

@fengjiachun 了解了，感谢解惑！

from jupiter.