Rocket® AppServer (formerly part of Micro Focus)

Summary

Avoiding ClosedByInterruptException when using Socket NIO

Setting threadMaxIdle when using Socket NIO

Socket NIO, threadMaxIdle and ClosedByInterruptException

Environment

VisiBroker 8.5

All Supported Platforms

Java Socket NIO

Question/Problem Description

When using Java Socket NIO, VisiBroker servers occasionally report the following exception:

org.omg.CORBA.COMM_FAILURE: java.nio.channels.ClosedByInterruptException

Clarifying Information

In order to help minimise the memory usage of server applications, VisiBroker provides the property:

vbroker.se.<se_name>.scm.<scm_name>.dispatcher.threadMaxIdle

This property specifies how long a worker thread can remain idle before VisiBroker’s internal garbage collector destroys it.

For detailed information on the “threadMaxIdle” property, please see our knowledgebase article entitled "Thread Pool Dispatcher threadMaxIdle".

Additionally, VisiBroker also provides the ability to use server-side, Java socket non-blocking IO (Java NIO). This can help reduce the number of threads required by the server to accept and read incoming requests.

For detailed information on using Java NIO, please see our knowledgebase entitled "Behavior difference between NIO and blocking IO in VisiBroker".

Error Message

org.omg.CORBA.COMM_FAILURE: java.nio.channels.ClosedByInterruptException

Defect/Enhancement Number

RPI 1104601

Cause

Under certain circumstances, the VisiBroker garbage collector may attempt to destroy a worker thread, while it is reading from a Java NIO SocketChannel. This can occur under the following conditions:

• If the "threadMaxIdle" property is set to a low value
• If Java Non-blocking IO is in use

The above scenario ultimately results in a CORBA communication failure. The server reports:

org.omg.CORBA.COMM_FAILURE: java.nio.channels.ClosedByInterruptException

Workaround

To avoid this CORBA communication exception, we recommend increasing the threadMaxIdle value. This change aims to reduce the frequency by which idle threads are destroyed.

Destroying idle threads less frequently can increase the memory footprint of the application, as the idle threads' local information remains in storage.

Similarly, destroying idle threads less frequently can improve the application's performance, as it reduces the overhead of destroying old threads and recreating new ones.