Communication Point Threads

Communication point threads are organized by the folder hierarchy. For an example, refer to the Communication Point Types page. This enables threads for specific communication points to be found quickly, even when a large number are running. There are two types of communication point threads:

Controller Threads - the communication point controller thread is responsible for creating new connections, and managing the communication point state. The communication point stops when the controller thread exits.
Connection Threads - the communication point connection threads run the individual communication point connections. There are either two (for bidirectional communication points) or one (all other communication points) threads per connection. The communication point can continue to run even when the connection threads exit (depending on the retry settings and the type of communication point).

Communication point threads cannot be interrupted or stopped by the user if they are currently in one of the following states and have been so for less than 1 minute:

Stopping.
Stopped.
Initializing new connection.
Saving message to Rhapsody.
Registering message for tracking.
Processing tracking response.

Additionally, controller threads cannot be interrupted or stopped by the user if they are waiting for connections to close while stopping, and have been so for less than 2 minutes.

Any attempt to interrupt or stop a communication point thread in one of these conditions will fail. The threads page is redisplayed with an error message indicating the problem.

Interrupting a connection thread will sometimes cause the connection to be closed. This is intended, but there is no guarantee that this will work. Stopping a connection thread will close the connection.
Interrupting a controller thread will generally cause the communication point to be shut down. This is intended, but if the controller thread is blocked the communication point may not be shut down. Stopping the controller thread will shut down the communication point.

Field/Action	Description
Communication Point	The communication point that the threads belong to. This is a hyperlink to the Communication Point Details page. Communication point threads are organized by the folder hierarchy (as on the communication points page). This enables threads for specific communication points to be found quickly, even when a large number are running.
Thread Name	The internal thread name. A running communication point has one controller thread, and one or two threads per active connection.
State	The thread state, which differs depending on the thread type. Communication point connection threads will have the following states: Starting. Stopping. Receiving message. Saving message to Rhapsody. Waiting for message to send. Sending message. Waiting to perform retry. Throttling. Registering message for tracking. Processing tracking response. Bidirectional communication points have two threads per connection. Communication point controller threads will have the following states: Starting. Stopping. Establishing new connection. Initializing new connection Maximum connections reached - waiting for connection to close.
Time in State	The amount of time the thread has been in its current state. `< 1 second` - if less than a second. The number of seconds - if less than a minute. The number of minutes - if less than an hour. The number of hours - if greater than an hour.
Thread Actions	Stack Trace - Opens a popup window showing a stack trace for the thread. A popup window is used to allow multiple stack traces of different threads to open simultaneously, without having to pre-generate the stack traces before displaying this page. Disconnect - Disconnects the communication point connection. The underlying connection is disconnected, but the thread itself is normally not touched. The communication point will generally continue to run (depends on the retry settings and communication point type). This is primarily relevant for TCP-based connections where the internal socket is closed. Interrupt - Interrupts the thread. You must confirm this action. This sets a flag on the thread letting it know it has been interrupted. If the thread is blocked performing some operation, it normally wakes up immediately and processes the interrupt. If the thread is busy, it may not notice the interrupt. While Rhapsody handles interrupts correctly, examples for existing Java code have shown incorrect ways of doing this. If you write a custom component that does not handle interrupts correctly, then it may do nothing. Interrupts are generally ignored if the thread is blocked within native code. Terminate - Stops the thread. You must confirm this action. This calls the `Java Thread.stop()` method. This does not terminate the thread immediately, but causes it to throw `ThreadDeath` internally. This will almost always break out of any Java code, however, it is not likely to have an effect if the thread is stuck within native code. Stopping a connection thread will only stop the connection. The communication point will generally keep running (depending on the type of communication point and the retry settings). The communication point will detect that it has less than the maximum number of connections, and will recreate the connection. Rhapsody will automatically create a new thread to take the place of the thread that has been stopped.