The Network Swiftlet is the interface for SwiftMQ Swiftlets to the network. This version utilizes the new java.nio API for nonblocking I/O. JDK 1.4 is required.
Nonblocking I/O is based on so-called selectors which control a set of connections for events. These events, such as read-ready, write-ready, accept-ready are returned and the appropriate actions are performed, such as read. The big advantage is that only 1 thread is required to watch many concurrent connections (instead of 1 thread per input stream for blocking I/O). This reduces a lot the thread consumption and the context switching. The data is read in a nonblocking manner. Only that data is read from the input channels which is available. With blocking I/O, a thread will block if no data is available.
Nonblocking I/O with selectors has some overhead which makes it slower than blocking I/O if only a few concurrent connections are involved. Our experience from scalability tests are that nonblocking I/O is reasonable if the number of concurrent connections is higher than 500. Below that, blocking I/O with the standard Network Swiftlet is recommended.
The behavior of events concerning outbound writes (router to client) in a nonblocking manner (OP_WRITE) wasn't unique on different platforms as for JDK 1.4.0. Therefore, it exists an attribute "use-op-write-events" in the Network NIO Swiftlet's configuration to toggle the registration for that events on and off. The default is on, thus, once a protocol handler is unable to write to a nonblocking channel, it registers a OP_WRITE interest on that channel and continues once the selector reports a "write-ready". If this attribute is toggled off (false), the protocol handler conitinues with attempts to write to the channel until all bytes have been written. This might lead to heavy CPU utilization on some platforms. We therefore recommend to use the default value "true" and use JDK 1.4.2 or later.
Once an interest for OP_WRITE events is registered, the output stream blocks until the event arrives and then continues writing. The maximum time for a stream to block is specified in attribute "op-write-max-wait-time". The default is 100 ms.
If a JMS client runs out of memory, it could be that the client side thread which reads from the socket stream doesn't work anymore. However, the TCP socket is still open and the router might try to send on this socket channel. At some point, when the TCP buffers gets filled, the channel will report EAGAIN and the Network NIO Swiftlet registers for OP_WRITE (see section above). Because no exception will be thrown from the socket channel but it reports continuously EAGAIN, this situation will turn into an endless loop until someone kills the JMS client process. To detect this EAGAIN situation, the Network NIO Swiftlet 5.0.1 introduces the attribute "eagain-disconnect-threshold" with a default value of 20. It means that the connection will be terminated after the channel reports continously 20 EAGAINs. The disconnect happens on the 21th EAGAIN. The disconnect will be reported in the warning.log.
The java.nio package has a channel based design and therefore socket factories cannot be used to create sockets. Prior to JDK 1.5 there was no possibility to use SSL in conjunction with java.nio. This has been changed as for JDK 1.5.0 which introduces SSLEngine. The Network NIO Swiftlet 5.2.0 now supports SSL but requires JDK 1.5.0 or above for the SwiftMQ router. The configuration of SSL ports is compatible with the standard Network Swiftlet. That is, if the socket factory "com.swiftmq.net.JSSESocketFactory" is defined, SSL will be used. The socket factory "com.swiftmq.net.JSSESocketFactory" is only used as a marker. It will not be used as a socket factory. This is for compatibility reasons.
Outbound HTTP tunneling (initated from the Network NIO Swiftlet, e.g. a routing connector) is not possible with the Network NIO Swiftlet. Inbound HTTP tunneling (from clients) can be used however.
Both versions of the Network Swiftlet support reliable IP multicast through the Lightweight Reliable IP Multicast Protocol (LRMP). To use publish/subscribe over IP multicast, one has to install the Multicast Extension Swiftlet. LRMP has a profil with several configuration properties. SwiftMQ provides similar attributes which are mapped directly to LRMP. Read the following white paper for a detailed introduction into LRMP.
Zombi connections are those connections that are created but where no data is sent. Since the keepalive has not been started yet, these connection were never closed in the past. Zombi connections can occur if, for example, SwiftMQ is monitored by opening telnet connections on a JMS listener port and also by DoS attacks. To prevent that zombi connections brings the router down, attribute "zombi-connection-timeout" can be set to a millisecond value, e.g. 10000 (10 secs). The Network Swiftlet then starts a timer on each connect and disconnects the connection if the protocol has not been initiated when the timer fires.