应用程序容器中的守护程序线程

时间:2022-04-04 20:59:27

I read in a post to the Smack forum recently that

我最近在Smack论坛上看了一篇帖子

Starting daemon threads in a Java EE server is a big no no

在Java EE服务器中启动守护程序线程是一个很大的问题

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 ?

基本上,Smack的XMPPConnection启动一个守护程序线程来监视传入的数据,另一个守护程序线程分别从jabber服务器向jabber服务器发送传出数据。在这种情况下使用守护程序线程来监听写/读是否合理?

2 个解决方案

#1


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.

是的,XMPPConnection创建了两个线程 - 一个用于监听/读取,一个用于写入。但是这些只有XMPPConnection实例才有效,我认为这不是永远的。

"Starting daemon threads in a Java EE server is a big no no"

“在Java EE服务器中启动守护程序线程是不可能的”

Are you writing spec compliant EJB? If so, then this applies. The spec says don't do it. EJB 2.1 specification:

你在编写符合规范的EJB吗?如果是这样,那么这适用。规范说不要这样做。 EJB 2.1规范:

"The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups."

“企业bean不得尝试管理线程。企业bean不得尝试启动,停止,暂停或恢复线程,或更改线程的优先级或名称。企业bean不得尝试管理线程组。”

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.

或者它只是一个恰好在Tomcat中运行的webapp?如果是这种情况,那么我没有看到任何根本问题。没有线程,您的Smack客户端将无法与服务器通信。

#2


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.

我只使用Smack API进行客户端连接,这些都是独立的程序。首先,您应该重新审视J2EE容器中Smack API的选择(或目的)。

#1


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.

是的,XMPPConnection创建了两个线程 - 一个用于监听/读取,一个用于写入。但是这些只有XMPPConnection实例才有效,我认为这不是永远的。

"Starting daemon threads in a Java EE server is a big no no"

“在Java EE服务器中启动守护程序线程是不可能的”

Are you writing spec compliant EJB? If so, then this applies. The spec says don't do it. EJB 2.1 specification:

你在编写符合规范的EJB吗?如果是这样,那么这适用。规范说不要这样做。 EJB 2.1规范:

"The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups."

“企业bean不得尝试管理线程。企业bean不得尝试启动,停止,暂停或恢复线程,或更改线程的优先级或名称。企业bean不得尝试管理线程组。”

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.

或者它只是一个恰好在Tomcat中运行的webapp?如果是这种情况,那么我没有看到任何根本问题。没有线程,您的Smack客户端将无法与服务器通信。

#2


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.

我只使用Smack API进行客户端连接,这些都是独立的程序。首先,您应该重新审视J2EE容器中Smack API的选择(或目的)。