Connection management
TCP/IP connections are requested by the client connection manager and accepted by the server connection manager.
The integration server process contains the connection manager, which makes the connections. Only one integration server can have TCPIP server nodes using a specific port at any one time; deployment to a second integration server causes a deployment error. TCPIP client nodes can be deployed to different integration servers, but each integration server has its own pool of connections, and therefore its own minimum and maximum number of connections.
- Host name and port
- Name of a policy
If a host name and port are specified, the TCPIP node uses these values when it requests connections. If a policy is specified, the node obtains the values for the port and host name from the values that are defined in the policy. The connection manager supports other configurable parameters in addition to the host name and port, and you can define all of these values when you are using a policy. When the host name and port are specified on the node, the connection manager obtains the rest of the required values from the default policy. However, if a policy is defined that is using the host name and port number, the values from that policy are used.
The connection manager is created when the first TCPIP node that requires connections from it is deployed. The connection manager is deleted when the last remaining node that uses it is removed from the integration server (which means that the connection manager is no longer being used by any deployed nodes). For example, this process can occur when existing flows are redeployed, because redeployment involves deleting all existing nodes before creating them again.
The connection manager applies any changes that are made to a TCPIP Client policy without requiring a restart of integration servers. The connection manager applies the TCPIP policy changes to all of the message flows that use that service. Applying TCPIP policy changes implies restarting the TCPIP connection managers, so all flows that use policies to specify TCPIP parameters can be expected to pick up new TCPIP connections.
The connection manager updates the affected TCPIP nodes only after every affected message flow has processed the current message. When an affected message flow has processed the current message, that message flow is locked until the updates to all affected message flows are complete. This process is to ensure that each node that is contained in the same integration server uses the same value for the modified policy. For this reason, there might be a delay of several seconds between applying the update to the policy, and the properties that are used by the message flow being updated.
mqsireportproperties INODE -e default -o TCPIP -rServer connections
The server connection manager starts listening for server connections when it starts, and it keeps accepting connections until the maximum number of connections (as specified in the policy) is reached. Any attempts to make connections after this point are refused. TCP/IP servers do not create connections; they accept connection requests only from other applications. As a result, you cannot force the creation of connections within a message flow.
Connections to servers can be started, stopped, or quiesced. If you quiesce a connection, you must set a timeout value, or else quiescing continues forever. You can administer the connections by using the IBM® Integration API, or the mqsichangeproperties command.
Client connections
The client connection manager starts and keeps making client connections until the minimum number of connections (as defined in the policy) is reached. By default, the minimum number of connections is zero, which means that no connections are made. Whenever the number of connections drops below the minimum value, the connection manager starts creating more client connections. The TCPIP client output and receive nodes initiate the creation of new client connections whenever none are available for them to use, unless the maximum number (as defined in the policy) has been reached.
Reserving and releasing connections
Each connection has an input stream and an output stream, both of which have two main states within the connection manager: available and reserved.
When a TCPIP node requests a connection for input or output, without specifying the ID of a particular connection, it is given any available connection on the required stream. If no connections are available, and if the node is a client node, a new connection is made, but only if the maximum number of connections has not yet been reached. Any connection in the available state can be used by only one node at a time, but when a node has finished using it, any other node (from any flow or thread) can access it.
You can restrict access to a stream on a connection by reserving the connection. When a connection is in the reserved state, no other node can access the stream without specifying the ID of the connection. For example, an input node can request an available connection, and, when it has finished reading the data, put the stream into the reserved state. While the stream is in the reserved state, no input node (including the node that put the stream into the reserved state) can access it because input nodes can access only available streams. The only nodes that can access the stream must have the connection ID, which is written to the outgoing local environment when the data is passed down the message flow. As a result, receive nodes can read more data on the same connection, but only if the receive node is configured to use the ID from the local environment of the input node.
When a connection is reserved, ownership of the connection is given to a current thread of processing. This processing can span separate message flows, if required.
- Leave unchanged
- Reserve
- Release
- Reserve and release at the end of the flow
For all nodes, the stream is left available (not reserved) by default. For many types of processing you can leave this default unchanged; for example, when you are moving data from an input stream to a file. The main purpose of reserving a stream is to connect a series of nodes to give complex processing on a stream in an ordered, controlled, synchronous sequence.
You can use the Reserve and release at end of flow option to reserve a connection and to ensure that the connection's stream is released when one iteration of the message flow has finished processing (including any error conditions that might occur).
If you require the processing to span multiple message flows (for example, for asynchronous request and reply), you must reserve a stream without releasing it at the end of the message flow.
A disadvantage of reserving a stream between message flows is the potential for a stream never to be released. To avoid this problem, set an expiry time on the connection so that it is closed after a specified period of inactivity.
Another benefit of reserving an input stream is that the connection cannot be closed until it is either released or expired (even if an end application closes its end of the connection), which is useful when the end of the stream is being used to delimit messages in the stream.
File descriptors
Failed to create a client connection using hostname: '', port: ''. Reason: 'Invalid argument'- Change the MQSIJVERBOSE environment variable,
for example:
export MQSIJVERBOSE=-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider - Change the limit of maximum file handles to value instead of RLIM64_INFINITY