rmi 回调陷阱？
在RMI中进行回调时需要担心什么？我只需要一个简单的客户端通知机制来避免过度轮询。
我找到了一个 在线示例，它看起来非常简单，客户端只需实现一个扩展 Remote 的接口（就像服务器一样）并将其传递给服务器，然后服务器可以回调其方法。我猜测远程回调可以在任何线程上发生，所以我必须假设它将与我的客户端应用程序的正常线程异步。还有什么？
What do I need to worry about when doing callbacks in RMI? I just need a simple client notification mechanism to avoid excessive polling.
I found an online example and it looks pretty straightforward, the client just implements an interface that extends Remote (like the server does) and passes it to the server, which can then call back its methods. I'm guessing the remote callback can occur on any thread, so I have to assume it will be asynchronous to my client application's normal threads. What else is there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有两件事。
RMI 回调几乎肯定无法通过防火墙
RMI 回调在与原始客户端对服务器的调用不同的线程上执行。如果不考虑这一点，您可能会遇到意外的同步死锁。
Two things.
RMI callbacks almost certainly won't work through firewalls
RMI callbacks execute on a different thread from the original client call to the server. You can get unexpected synchronization deadlocks if you don't take that into account.