我有一个让我发疯的问题!无论是设计方面还是技术方面。 我需要收听大量的多播地址。我监控/收集的每个项目分为3组。我已经走上了让一个进程旋转100个线程的道路。每个线程使用2个端口和3个地址/组。 (其中2个组在同一个端口上)我正在为每个端口使用MulticastChannel,并使用SELECT监视数据。 (我使用过数据报,但发现NIO MulticastChannel要好得多)。 无论如何,我看到的问题是我可以订阅大约一千个这样的线程,并且数据很好地哼唱。问题是,过了一段时间我会让其中一些人停止接收数据。我已经向系统(CentOS)确认我仍然订阅了这些地址,但数据才停止。我的线程中有监视器,它通过RTP头监视数据丢失和无序。当我检测到线程已停止获取数据时,我执行DROP / JOIN,然后数据恢复。
I have an issue that is driving me crazy! Both design-wise and tech-wise. I have a need to listen to a LOT of multicast addresses. They are divided into 3 groups per item that I am monitoring/collecting. I have gone down the road of having one process spin-up 100 threads. Each thread uses 2 ports, and three addresses/groups. (2 of the groups are on same port) I am using MulticastChannel for each port, and using SELECT to monitor for data. (I have used datagram but found NIO MulticastChannel much better). Anyway, I am seeing issues where I can subscribe to about a thousand of these threads, and data hums along nicely. Problem is, after a while I will have some of them stop receiving data. I have confirmed with the system (CentOS) that I am still subscribed to these addresses, but data just stops. I have monitors in my threads that monitor data drops and out-of-order via the RTP headers. When I detect that a thread has stopped getting data, I do a DROP/JOIN, and data then resumes.