java RMI 和/或 JNDI：绑定非单例对象
好的，我了解了如何使用 RMI 将单例服务器对象与众所周知的名称绑定在一起，以便其他 JVM 可以找到它。
假设我有多个进程，每个进程都运行一个 JVM，并且每个进程都创建一个支持 FooRemote 接口的对象，我希望通过 RMI 公开该接口。每个进程都有一个不可预测的生命周期，与某些事物相对应，无论是来自用户输入，还是资源的可用性。
如何绑定它们而不发生命名冲突？使用 JNDI 有帮助吗？
实际上，我想做的是拥有一个类似对象的池，每个对象都位于单独的 JVM 上（这样做的原因很重要，但超出了这个问题的范围）。我需要一个客户端能够枚举哪些对象可用，并选择一个进行进一步交互。
（我强调单独的 JVM 的原因是，如果它们都在同一个 JVM 中，我可以有一个处理组池的单例管理器，并使所有组实例都可以通过管理器访问。但我不能这样做如果组池由单独 JVM 中的独立实例组成）。
OK, I get how to use RMI to bind a singleton server object with a well-known name so that other JVMs can find it.
Let's say I have a number of processes, each running a JVM, and each creating an object supporting the FooRemote interface, which I wish to expose via RMI. Each process has an unpredictable life cycle that corresponds to something, whether it is from user input, or availability of a resource.
How can I bind these without getting naming collisions? Would using JNDI help?
In effect, what I wish to do is to have a pool of similar objects, each on separate JVMs (reason for doing so is important but beyond the scope of this question). I need a client to be able to enumerate which objects are available, and choose one for further interaction.
(The reason I emphasize the separate JVMs is that if they were all in the same JVM, I could just have a singleton manager that handles the group pool, and make all the group instances accessible through the manager. But I can't do that if the group pool consists of independent instances in separate JVMs. )
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它不是很有效，但是您可以在每个 JVM 中拥有一个单例管理器（工厂），它创建并枚举池中属于该 JVM 的所有对象。
显然，你必须询问他们所有人才能了解全貌。这可能是也可能不是您想要的，具体取决于您的实际用例。虽然它是准确的，但网络流量和延迟会极大地影响性能，因此如果您查询池的次数多于更新池的次数，请不要尝试此操作。
另一种解决方案是将客户端转变为服务器，并允许服务器在池中对象的状态发生变化时调用回调。此解决方案在网络流量方面可能更高效，但更新程度较低：如果其中一台服务器突然终止，则其对象不会从池中删除，直到您实际尝试使用它们并失败为止。可以通过 keepalive 调用和超时来跟踪服务器的可用性来改进此行为，但显然会增加流量和解决方案的复杂性。
It's not very effective, but you can have a singleton manager (factory) in each JVM, which creates and enumerates all the objects in the pool that belong to that JVM.
You obviously have to ask them all to get the full picture. This may or may not be what you want depending on your actual use case. While it's accurate, network traffic and delays affect performance drastically, so don't try this if you're querying the pool a lot more than you update it.
Another solution is to turn your client into a server and allow servers to invoke a callback when the status of the objects in the pool change. This solution is probably more efficient in network traffic but is less up-to-date: if one of the servers terminate abruptly, its objects won't be removed from the pool until you actually try to use them and fail. This behaviour can be improved on by a keepalive call and a timeout to keep track of the availability of servers but obviously at the price of increasing the traffic and the complexity of your solution.