应用程序容器中的守护线程
我最近在 Smack 论坛的一篇帖子中读到
在 Java EE 服务器中启动守护线程是一个很大的禁忌
基本上 Smack 的 XMPPConnection 会启动一个守护线程来监视传入数据 & 另一个分别从 jabber 服务器发送传出数据/向 jabber 服务器发送传出数据。 在这种情况下使用守护线程来监听写入/读取是否合理？
I read in a post to the Smack forum recently that
Starting daemon threads in a Java EE server is a big no no
Basically Smack's XMPPConnection starts one daemon thread to monitor incoming data
& another to send outgoing data from/to the jabber server respectively. Is it reasonable to use daemon threads to listen for write/reads in this scenario ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，XMPPConnection 创建两个线程——一个用于监听/读取，一个用于写入。 但这些仅与 XMPPConnection 实例一样长，我认为这不会永远存在。
您是否正在编写符合规范的 EJB？ 如果是这样，那么这适用。 规范说不要这样做。 EJB 2.1 规范：
？如果是这种情况，那么我没有看到任何根本问题。如果没有线程，您的 Smack 客户端将无法与服务器通信。
Yes, XMPPConnection creates two threads--one for listening/reading and one for writing. But these only live as long as the XMPPConnection instance, which I assume is not forever.
Are you writing spec compliant EJB? If so, then this applies. The spec says don't do it. EJB 2.1 specification:
Or is it just a webapp that happens to be running in Tomcat? If this is the case, then I do not see any fundamental problem. Without the threads, your Smack client would be unable to communicate with the server.
我仅将 Smack API 用于客户端连接，这是独立的程序。 首先，您应该重新审视 J2EE 容器内 Smack API 的选择（或目的）。
I have used Smack API for client connections only which are stand alone programs. First you should revisit the choice (or purpose) of Smack API inside a J2EE container.