Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Socket NIO server reports ClosedByInterruptException

Socket NIO server reports ClosedByInterruptException


Avoiding ClosedByInterruptException when using Socket NIO

Setting threadMaxIdle when using Socket NIO

Socket NIO, threadMaxIdle and ClosedByInterruptException


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:


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


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


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.


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Version history
Revision #:
1 of 1
Last update:
‎2016-05-04 11:44
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.