FULL PRODUCT VERSION :
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Happens on Solaris:
SunOS sunfile 5.8 Generic_108528-22 sun4u sparc SUNW,Ultra-30
and Linux:
Linux forge.blast.com 2.4.22-1.2174.nptl #1 Web Feb 18 16:38:32 EST 2004 i686 i686 i386 GNU/Linux




EXTRA RELEVANT SYSTEM CONFIGURATION :
The sample code I have included needed a server to talk to so I have it connect to an smtp host and then send the QUIT command.  You just need to set the hostname to make it work.  Otherwise you need to modify the code to do other communications.

A DESCRIPTION OF THE PROBLEM :
There is a file descriptor leak when using SocketChannels.  The sockets that get created all end up in CLOSE_WAIT state and not cleaned up until the process exits.

Additionally (on Linux at least) there is a Pipe allocated for each channel used in the sample which is never released.

I have included a sample piece of code that when run will continually leak file descriptors on JDK 1.4.2.  It appears that it happens on all platforms but is easiest to reproduce on Solaris or Linux (for me at least)  I have seen a number of bugs written that  mention

The appears to occur only in to following conditions:

1. When SocketChannel.socket.setSoTimeout is called with a non-zero value
2. When a SocketChannel.socket.getInputStream().read() is called
3. When different threads make the calls
4. When the server side closes the socket sometime AFTER the first read returns.

I have been looking at the JDK source and have an understanding of what is happening.

a SocketChannel uses a SocketAdapter to emulate a Socket.  the getInputStream
method returns the SocketAdapter.SocketInputStream inner class.  the read(ByteBuffer)
method of SocketInputStream delegates to the channel UNLESS the timeout is set to nonzero.

In this case it uses a  temportary selector to block until the channel is readable.  This selector is stored in a SoftReference in ThreadLocal memory.   After the read is complete or the timer expires the SelectionKey assocatied with the Selelector and the Channel is cancelled in a finally block.

The causes two problem.

The first one is that even the the SelectionKey is cancelled, the selectNow method in not called on the selector.  So the channel stays registered until the same thread comes thru and does a similar read which causes the selector to be reused.  (That's why having a different thead each time aggravates this problem)  If the Selector is garbage collected before the next similar read by this thread then the select was never called and the channel remains registered until the Selector is closed.  In 1.4.1 the Selector had a finalizer that would close it and finally deregister the channel but the finilizer was removed 1.4.2 therefore these channels never get closed.  By adding the selectNow to the finally block here the channel will get deregistered immediately and the close of the channel should work as expected.

You can see the need to the selectNow even in 1.4.1 because the file descriptors don't get closed for a long time until the Selectors are finalized.  (There may be another bug on this)

The second problem that is caused here is that because the 1.4.2 finalizer was removed in the SelectorImpl the close method for these temporary Selectors never gets called.  This means that resources allocated by these Selectors never gets freed even if the  customer  gets garbage collected which is definitely a problem.

I understand that the finalizers were removed because it caused slowness in the garbage collector so if it is desirable not to have finallizers here then a different mechanism to close these selectors when they get garbage collected needs to be created.  These unfinalized selectors are causing the accumulation of PIPEs (FIFOs) that you see in an lsof listing of the sample program.

Please feel free to contact me if any of this is unclear.  And I'm more than happy to help in any way I can.

Matt Brozowski

PS If you put the selectNow code in... there are 3 or 4 other places that you should consider putting it in as well as the code for those blocks is nearly Identical to the one in SocketinputStream.read


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.  Paste the included source into the file TestClose.java
2. Modify the SMTP_HOSTNAME to be the name or address of a valid SMTP server that you can access
3. javac TestClose.java
4. java -classpath . TestClose

While the program is running run
    netstat -an

many times and take note of the number of sockets open and watch how they
change over time

Also run
   lsof -p <processid of java process>
if you have it and take note if it


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The program only opens one socket at a time.  I expect the number of open file descriptors used by the program to remain very low (under 10)

ACTUAL -
Instead the number increases until the program begins to throw Too Many Open Files exceptions.

In 1.4.1 in would use them up until the finalizers ran.. then they would all be cleaned up at once.  This may have been the cause for slowness of the finalizers and the reason they were removed.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.InetSocketAddress;
import java.net.Socket;
import java.nio.channels.SocketChannel;
import java.util.StringTokenizer;

// Test case code for file descriptor leak.
// The following should produce somewhere near 150 sockets in CLOSE_WAIT state.
//
// The problem appears to be in sun.nio.ch.SocketAdapter.SocketInputStream.read(ByteBuffer);
//

public class TestClose implements Runnable {
    
    public static final String SMTP_HOSTNAME = "myhandy.smtphost.com";

 	public void run()
	{
        InetSocketAddress sockAddr = new InetSocketAddress(SMTP_HOSTNAME, 25);
		SocketChannel sChannel = null;
		Socket socket = null;
		try
		{
			sChannel = SocketChannel.open();
			sChannel.connect(sockAddr);
            
            //  I've noticed that if I remove this line the problem no longer happens
			sChannel.socket().setSoTimeout(5000);
			
			socket = sChannel.socket();
			
			BufferedReader lineRdr = new BufferedReader(new InputStreamReader(socket.getInputStream()));
			
			
			String result = null;
			do
			{
                // before performing the first readline the channel is unregistered
				System.err.println("before first readline: isOpen = "+sChannel.isOpen()+" isRegistered="+sChannel.isRegistered());
                
				result = lineRdr.readLine();
				System.err.println("<- "+result);
                
                // after performing it is registered.
				System.err.println("after first readline: isOpen = "+sChannel.isOpen()+" isRegistered="+sChannel.isRegistered());
				
			} while(result != null && result.length() > 0 && result.matches("^[1-5][0-9]{2}-"));
			
			if(result == null || result.length() == 0)
			{
				System.err.println("Received truncated response from SMTP server " + sockAddr.getHostName());
				return;
			}
			
			// Tokenize the last line result
			//
			StringTokenizer t = new StringTokenizer(result);
			int rc = Integer.parseInt(t.nextToken());
			if(rc != 220) return;
			
			//
			// Send the QUIT command causing the server side to close its end of the connection
			//
			String cmd = "QUIT\r\n";
			socket.getOutputStream().write(cmd.getBytes());
			System.err.println("-> "+cmd);
			do
			{
				result = lineRdr.readLine();
				System.err.println("<- "+result);
			} while(result != null && result.length() > 0 && result.matches("^[1-5][0-9]{2}-"));
			
			if(result == null || result.length() == 0)
			{
				System.err.println("Received truncated response from SMTP server " + sockAddr.getHostName());
				return;
			}
			
		}
        catch (Exception e) {
            e.printStackTrace();
        }
		finally
		{
            try {
                
            	System.err.println("before close: isOpen = "+sChannel.isOpen()+" isRegistered="+sChannel.isRegistered());
			
            	System.err.println("Closing SMTP socket channel "+sChannel);
                System.err.println("channel.socket().isConnected = "+ sChannel.socket().isConnected());
            	if (sChannel != null) {
            		sChannel.close();
            		System.err.println("Closed SMTP socket channel "+sChannel);
                    
                    // The socket is still connected here.
            		System.err.println("channel.socket().isConnected = "+sChannel.socket().isConnected());
            	}
            }
            catch (Exception e) {
               System.err.println("Exception on close:");
               e.printStackTrace();
            }
		}
		
		return;
	}
    

	public static void main(String[] args) {
        TestClose test = new TestClose();
        for(int i = 0; i < 150; i++) {
         // this bug seems only to appear if different threads are reading the channels
        	Thread thread = new Thread(test);
            thread.start();
            try {thread.join(); } catch(InterruptedException e) {   }
        }
        
        System.err.println("Going to sleep.... run netstat -an | grep CLOSE_WAIT ");
        while(true) {
        	try { Thread.sleep(10000); } catch(InterruptedException e) {}
        }
	}
}



---------- END SOURCE ----------
  xxxxx@xxxxx   2005-1-07 06:48:46 GMT

N/A

The same problems described in 5083450, 4726957 and 4960962.
  xxxxx@xxxxx   2005-1-07 07:14:08 GMT
Note: The fix has been backported into 1.5u7.
Posted Date : 2006-02-09 21:46:30.0

--

Aug 18, 2006. A number of developers on the JDC have posted comments suggesting that his bug is not fixed in 5.0 update 7 on Linux. If you believe there is still a leak then please post a test case or leave a mail address so that we can follow up. So far all of the cases that we have examined have been cases where the closing of the file descriptor was delayed because the Selector is idle (meaning there aren't any events to wake it up). In those cases, the connection is closed but the file descriptor isn't released until the Selector wake ups.
Posted Date : 2006-08-18 14:36:21.0

The latest sdn comment (3 oct) says "In a relatively idle system that repeatedly polls a
deployment server for new artifacts, eventually I'll drain the avialable file descriptors
for the process leaving the VM wedged and unable to respond to new requests or make further
polling efforts. However, if I put the system under load such that full GCs are taking place,
the FDs are cleaned during the full GC."

Most likely this application creates a new thread everytime when need to "poll and process"
the request and then throws away the thread later. Yes, such a use scenario will cause a
temporary fd "leakage", before a GC kicks in. Part of fix of this bug is to have a
"phantom-reference-based cleaner" to clean/release up the fds used by the app thread (mostly
if the processing involves a "timeout" setting) when the thread is dead. So, yes, you need
the GC to start up the cleanup. In such a scenario, a thread poll is strongly recommended.
Not only the fd, the "thread" itself is also an expensive system resource, you might end up
of exhausting the thread resource before you hid the fd limit.

Let us know if this is not your case. And as mentioned above, it would be easy for us to
follow up if you can leave your contact info (email address).
Posted Date : 2006-10-04 22:11:44.0

This bug is NOT fixed - nor are the related bugs that are also marked closed.

We have opened a ticket with Sun on this - this should not be closed. We need to have a patch for this on JDK 1.5 and JDk 1.4 as needed.

Is there going to be a patch for 1.5? At least the 1.5.0_06 is still broken? (with linux)

I guess we can all stop talking about high performance java webservers?

This is a serious problem for us as it causes the app server to run out of sockets!
Apparently this has been fixed now on 1.5.07 and scheduled to be released on 4/24/06. 
Hopefully this major bug can be fixed earlier via patch update. We cannot really wait until 4/24/06.

Why is this bug and the related bugs closed? this bug isn't fixed. Under linux there are CLOSE_WAITs and not disappearing pipes and sockets, which you can see if you have a look to /proc/processID/fd...

what's going on?

The bug is fixed in mustang and also in 5.0u7. Since 5.0u7 isn't available yet can you verify that the issue does not duplicate with mustang?

Is there a plan for fixing this in the 1.4.2 code base?  Are there any suggested methods of avoiding the issue?

Thanks,

The issue is still seen with 1.5.0_01 on solaris sparc
Do we have a patch ?

Echo the 1.4.2 comments.  Where are we with 1.4.2 fixes or workarounds?

I'm seeing the bug still appearing in 1.4.2_12 and 1.5.0_7 (Solaris).  Can anyone else confirm?

java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_07-b03, mixed mode)

SuSE 10.1 AMD 64

Still seeing this bug. Web server is leaking sockets.

in fact, to be more precise (my post was the SuSE 10.1 above)

lsof reports:

java      5892         root    6u     sock                0,4               21604 can't identify protocol
java      5892         root   58u     sock                0,4               21965 can't identify protocol
java      5892         root   83u     sock                0,4               21833 can't identify protocol

This bug seems not to be closed. If we ar making a socket connection to localhost, to check the running web service from within the JVM, then there are remaining file descriptor's leaks:

Running on 1.50_07 on Redhat Linux 9:

>lsof -p 32190

[...]
java    32190 root  214u  IPv4 -166566432                 TCP *:9001 (LISTEN)
java    32190 root  215u  IPv4 -166566435                 TCP *:8001 (LISTEN)
java    32190 root  216r  FIFO        0,5          4128400865 pipe
java    32190 root  217w  FIFO        0,5          4128400865 pipe
java    32190 root  218u  IPv4 -166533668                 TCP localhost:44849->localhost:9001 (CLOSE_WAIT)
java    32190 root  219u  IPv4 -166566427                 TCP *:9002 (LISTEN)
java    32190 root  220r  FIFO        0,5          4128400870 pipe
java    32190 root  221w  FIFO        0,5          4128400870 pipe
java    32190 root  222u  IPv4 -166566425                 TCP *:9000 (LISTEN)
java    32190 root  223r  FIFO        0,5          4128400872 pipe
java    32190 root  224w  FIFO        0,5          4128400872 pipe
java    32190 root  225u  IPv4 -166501833                 TCP localhost:44876->localhost:9000 (CLOSE_WAIT)
java    32190 root  226u  IPv4 -166501829                 TCP localhost:44877->localhost:9001 (CLOSE_WAIT)
java    32190 root  227u  IPv4 -166501824                 TCP localhost:44878->localhost:9002 (CLOSE_WAIT)
java    32190 root  228u  IPv4 -166470458                 TCP localhost:44903->localhost:9000 (CLOSE_WAIT)
java    32190 root  229u  IPv4 -166470453                 TCP localhost:44904->localhost:9001 (CLOSE_WAIT)
java    32190 root  230u  IPv4 -166533661                 TCP localhost:44850->localhost:9002 (CLOSE_WAIT)
java    32190 root  231u  IPv4 -166470443                 TCP localhost:44907->localhost:9002 (CLOSE_WAIT)
java    32190 root  232u  IPv4 -166440129                 TCP localhost:44930->localhost:9000 (CLOSE_WAIT)
java    32190 root  233u  IPv4 -166533659                 TCP localhost:44851->localhost:9000 (CLOSE_WAIT)
java    32190 root  234u  IPv4 -166440124                 TCP localhost:44931->localhost:9001 (CLOSE_WAIT)
java    32190 root  235u  IPv4 -166438611                 TCP localhost:44934->localhost:9002 (CLOSE_WAIT)
java    32190 root  236u  IPv4 -166408735                 TCP localhost:44960->localhost:9000 (CLOSE_WAIT)
java    32190 root  237u  IPv4 -166408723                 TCP localhost:44963->localhost:9001 (CLOSE_WAIT)
java    32190 root  238u  IPv4 -166407216                 TCP localhost:44964->localhost:9002 (CLOSE_WAIT)

same here,

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode)

on RedHat ES 3.0

this bug should not be closed.  any way to reopen this?

I can confirm that this bug still exists with jdk 1.5.0_08 on Linux.

Despite claiming to be fixed (yet again) in 1.5.0_09, I'm still seeing the issue on a RHEL4 system.

Linux 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux

To elaborate on my posting from earlier today, in my environment anyway, this issue seems to be tied to the type of garbage collection that takes place. In a relatively idle system that repeatedly polls a deployment server for new artifacts, eventually I'll drain the avialable file descriptors for the process leaving the VM wedged and unable to respond to new requests or make further polling efforts. However, if I put the system under load such that full GCs are taking place, the FDs are cleaned during the full GC. 

I've also confirmed this behavior by leaving the system idle long enough to accumulate several 100 CLOSE_WAIT sockets, then attaching a jconsole, invoking a full GC, then seeing CLOSE_WAIT sockets go to 0. 

Given the nature of this application, it's possible that it sits idle for extended periods of time never producing enough activity for a full GC and ultimately hiting the process limits.  Although I suppose I could up the ulimit for the process, that's not really adressing the problem.

Hi folks,

I figured out a workaround on my machine (Linux 2.4, JVM 1.5.0_08). The idea behind is that I read on the selector after closing the channel. This causes the TCP states to exchange. 

Maybe you can try?


This is my selector close method:

private void close() throws IOException {
      _isrunning = false;
      _state = STATE_CLOSING;
      while ( _state == STATE_CLOSING ) {
        int n = _selector.select( 500 );
        if ( _selector.keys().isEmpty() ) {
          // Now we can finally close
          _state = STATE_CLOSED;
        }
        else {
          // read again for shutdown state exchange
          int numbytes = readChannel();
          if ( numbytes == -1 ) {
            // Channel is definitly closed
            _channel.close();
          }
        }
      }
      _selector.close();
      _selector = null;
    }

it's not fixed nor on 1.4.* neither on 1.5.* and caused serious problem in intensive environment with high network load. also, this bug is applied to DatagramSocketChannel. once DatagramSocketChannel.socket() is called another file descriptor is reserved. even more, after this call close method on channel doesn't free its own file handler so with each call system leaks 2 fd's.
please reopen this and fix it.

The fd leakage problem when using  DatagramSocketChannel.socket() has been fixed in JDK6 and 5.0u7 (5.0 updated release 7), which is traced under #6246565.  Please let me know if you still see the leak in 5.0u7 (appreciate if you can attach a test case).

As I mentioned  above (in Evaluation), a number of developers have posted comments suggesting that this bug has not been fixed, though we've verified that the test case attached in this bug report no longer causes fd leakage and  believe the channel leakage issue has been fixed, we are interested to see if we are missing anything here (and will fix it if we do stil have an issue), so please post a test case or leave us an email address so we can followup. I included my email address just in case you want to talk to me directly.

Btw, does the suggested workaround post on Oct.2th suggest that you are not explicitly closing the socketchannel and  expecting the vm will close it "automately" after you closed the selector? just  in case my wild guess is correct ,  yes, the channel needs to be closed explicitly.

Xueming
 

Seems like the "include a link with my name&email" does not mean it will figure out my email address and attach it automately:-) Here we go "xueming.shen@sun.com"

There is a simple workaround for this kind of problem. 
Call  
   sChannel.socket().shutdownInput();
   sChannel.socket().shutdownOutput();
before calling
   sChannel.close();

Tiberiu Covaci
BEA JRockit (R) engineer

I'm seeing fd leaks also in 5u9.

I also have a process that is idle for long periods, occasionally polling another server via a socket connection.  Although I close the socket (and also shutdown input & output first).  And null everything, I still see fd leakage after every polling, seems to be 3 fd per poll for some reason.


Linux white 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23 UTC 2006 i686 athlon i386 GNU/Linux

java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)

email for followup on last post.  
peter_bridge at hotmail.com

Fixed in JDK 5.0 u10:

java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)

I still see a similar issue even with JDK 5.0 u10.  The socket does get closed (disappears with netstat), but lsof shows two pipes still in existence and also the IPv6 / TCP line becomes unix/socket and the three descriptors never get cleaned up.  Here's a partial lsof listing:

java    16772 bgroves   73u  unix 0x00000102122cf380            752076 socket
java    16772 bgroves   74r  FIFO                0,7            758045 pipe
java    16772 bgroves   75w  FIFO                0,7            758045 pipe
java    16772 bgroves   76u  unix 0x00000102122cf380            752076 socket
java    16772 bgroves   77r  FIFO                0,7            758347 pipe
java    16772 bgroves   78w  FIFO                0,7            758347 pipe
java    16772 bgroves   79u  unix 0x00000102122cf380            752076 socket
java    16772 bgroves   80r  FIFO                0,7            758679 pipe
java    16772 bgroves   81w  FIFO                0,7            758679 pipe
java    16772 bgroves   82u  IPv6             758680               TCP manassas:40170->manassas:51872 (ESTABLISHED)


This occurs any time the remote client drops the link (either gracefully via close() or going down hard).  Here is the cleanup code which doesn't really clean up:

   public void disconnect() {
      System.out.println("Disconnecting");
      try {
         if (mAcceptingConnector != null) {
            mAcceptingConnector.close();
            mAcceptingConnector = null;
         }
      } catch (Exception e) {
         System.out.println("Exception " + e
               + " occurred while closing accepting connector");
      }

      try {
         if (mUpstreamServerSocketChannel != null) {
            mUpstreamServerSocketChannel.close();
            mUpstreamServerSocketChannel = null;
         }
      } catch (Exception e) {
         System.out.println("Exception " + e
               + " occurred while closing upstream server socket channel");
      }
       
      try {
         if (mUpstreamSocketChannel != null) {
        	 Socket actualSocket = mUpstreamSocketChannel.socket();
        	 if (actualSocket != null) {
        		 InputStream is = null;
        		 OutputStream os = null;
        		
        		 try {
            		 is = actualSocket.getInputStream();
        		 } catch (Exception e) {
        			 System.out.println("Exception " + e + " occurred getting input stream to close");
        		 }

        		 try {
            		 os = actualSocket.getOutputStream();
        		 } catch (Exception e) {
        			 System.out.println("Exception " + e + " occurred getting output stream to close");
        		 }
        		 
        		 if (is != null) {
        			 is.close();
        		 } else {
        			 System.out.println("Not closing null input stream");
        		 }
        		 
        		 if (os != null) {
        			 os.close();
        		 } else {
        			 System.out.println("Not closing null output stream");
        		 }
        		 
        		 System.out.println("Closing " + actualSocket.toString());
        		 actualSocket.close();
        	 }
            mUpstreamSocketChannel.close();
            mUpstreamSocketChannel = null;
         }
      } catch (Exception e) {
         System.out.println("Exception " + e
               + " occurred while closing upstream socket channel");
         e.printStackTrace();
      }

      try {
         mUpstreamReadingSelector = null;
         mPortsOpen = false;
      } catch (Exception e) {
         System.out.println("Exception " + e
               + " occurred while disconnecting from OTCMR");
      }
   }


None of the exception paths are hit (i.e., the only messages printed from the above are "Disconnecting" and "Closing <socket>".

Can some one confirm whether this is fixed in 1.4.2?

Hi, 

this bug is definitively not complety fixed. If the remote server crashes the connection on the local machine is not cleaned up properly.

Or machine is running linux with JDK 1.5.0_10-b03.

Christian

Still existing in the version below.  Open ports don't get closed until GC.

java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode)

Hi,

We are seeing the same kind of response with our implementation, CLOSE_WAITS after client calls the ESB. Does anyone know is it a JDK issue or Linux, please respond to my email ID: garyhassan@gmail.com 

Hi,

I have a small Java program using non-blocking ChannelSocket and it leaks File descriptors (Sockets never closed) as described in bug 6215050

I have tested on the following:
 Linux RHEL 4 2.6.9-5.EL Sun JDK 1.5.0_11
 Linux RHEL 4 Sun JDK 1.6.0_04
 Linux RHEL 4 Bea JRockit 1.6.0_02
 Ubuntu Linux 7.10 server 2.6.22-14 Bea JRockit 1.6.0_02
all with the same result.

I have tested a great number of suggested work arounds without success.
The socketChannel.socket().setKeepAlive(true); seems to make the number of "pipe" file descriptors less, but the problem remains and eventually the process stops.

Is this a Linux problem or Java problem?

/Roland

I am facing the same problem while using rox XML-RPC client. I am using this xml-rpc client for connecting to a xml-rpc server for every 5 seconds. After 10 mins I am getting the following exception in my log file.

java.io.IOException: Too many open files
        at sun.nio.ch.DevPollArrayWrapper.init(Native Method)
        at sun.nio.ch.DevPollArrayWrapper.<init>(DevPollArrayWrapper.java:69)
        at sun.nio.ch.DevPollSelectorImpl.<init>(DevPollSelectorImpl.java:54)
        at sun.nio.ch.DevPollSelectorProvider.openSelector(DevPollSelectorProvider.java:18)
        at com.flat502.rox.processing.ChannelSelector.<init>(ChannelSelector.java:34)
        at com.flat502.rox.processing.ResourcePool.newChannelSelector(ResourcePool.java:166)
        at com.flat502.rox.processing.ResourcePool.getChannelSelector(ResourcePool.java:32)
        at com.flat502.rox.processing.HttpRpcProcessor.initialize(HttpRpcProcessor.java:471)
        at com.flat502.rox.client.HttpRpcClient.initialize(HttpRpcClient.java:735)
        at com.flat502.rox.client.HttpRpcClient.<init>(HttpRpcClient.java:117)
        at com.flat502.rox.client.XmlRpcClient.<init>(XmlRpcClient.java:66)
        at com.flat502.rox.client.XmlRpcClient.<init>(XmlRpcClient.java:62)
        at com.smsaggregator.RequestManager.recieveSMSRequests(RequestManager.java:140)
        at com.smsaggregator.RequestManager.run(RequestManager.java:262)
        at java.lang.Thread.run(Thread.java:595)
I am using the following env for development.

SunOS SCKN567H 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-4

java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Server VM (build 1.5.0_15-b04, mixed mode)

Number of open pipes growing when using nio SocketChannel (memcached JAVA client implementation).

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed mode)

Linux:  2.6.9-11.ELsmp #1 SMP Fri May 20 18:25:30 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux

Tested with 1.5.0_16: Same results.
Tried to call    
sChannel.socket().shutdownInput();
sChannel.socket().shutdownOutput();
before sChannel.socket().close();

Still not working.

It is really a critical bug: we are using memcached API based on a connection pool. The number of open file is growing very quickly (pipes not closed).
I really do not understand why it is not fixed or why a proper work around is not available.