You may encounter a situation where ColdFusion locks up and appears not to be servicing requests. When you inspect the request queue with FusionReactor, you notice a lot of requests are executing. A thread dump indicates many threads stuck in the method java.net.SocketOutputStream.socketWrite0.
The following is a sample stack trace in which the situation exhibits:
This method, which is native C code, handles the actual transmission of page data from the J2EE container onto the network, either for direct transmission to a client, or for subsequent marshalling by an intermediate web server (e.g. IIS). Some clients (in particular, some older versions of Internet Explorer) exhibit a bug whereby they consume the transferred data, but fail to shut down the socket.
The issue stems from the fact that internally, ColdFusion's web server connectors appear to have an internal buffer of 64KB, regardless of how big the ColdFusion page buffer is set. This buffer is filled by ColdFusion on a <cfflush> command (or when the page is complete, or the CF page buffer is full). The flush operation causes the buffer to be written to the network, and for the client to reply that it has received it all correctly. If the client does not properly close the connection, or another network issue occurs, the next flush of page data by ColdFusion down to this buffer will cause the thread to hang.
The connection on the server therefore remains active in the socketWrite0 method, and eventually all worker threads are consumed, ending up locked in this state.
ColdFusion is unable to perform operations on these threads since they are executing a native method. Any operation on these threads is flagged for execution when the native method returns – which it never does. Because TCP/IP handshake data is still being serviced by the client, the server believes the connection is alive, and it is never timed out.
The Socket Buffering crash protection attempts to alleviate this problem by:
- Increasing the size of the Java (ColdFusion) page buffer to a larger value than default, to increase the likelihood that the entire page can be buffered and sent in one operation;
- Discarding ColdFusion flush commands after the first 64KB of data is buffered, preventing a flush from locking the thread.
- Shut down the ColdFusion instance you're monitoring with FusionReactor
- Locate the reactor.conf file for your instance.
- This will be in /FusionReactor/instances/INSTANCE_NAME/conf
- Back up this file somewhere safe.
- Edit this file, adding the following line to the end:
- Restart the instance.
- Because of the complexity of the buffering mechanism, and the large variety of ways it is employed, we still consider this feature experimental, and it is therefore not exposed in the user interface.
- If you rely on cfflush for page building, be aware that flushes subsequent to the 64KB mark may not be honoured. The remaining data will be flushed to the network when the page completes.
This feature is available in FusionReactor 3.0.1 and later.
|Last Updated:||03/Nov/11 2:20 PM|
|Fixed Version:||3.5, 4.0.0|
|Server:||ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9|