the opened Selector is not closed in MemcachedConnection if error occurs

[GoogleCodeExporter]

version=2.01,os=linux?

Tell me more...

      public MemcachedConnection(int bufSize, ConnectionFactory f,

                 List<InetSocketAddress> a)

           throws IOException {

           reconnectQueue=new TreeMap<Long, MemcachedNode>();

           addedQueue=new ConcurrentLinkedQueue<MemcachedNode>();

           selector=Selector.open();

           List<MemcachedNode> connections=new
ArrayList<MemcachedNode>(a.size());

           for(SocketAddress sa : a) {

                 SocketChannel ch=SocketChannel.open();

                 ch.configureBlocking(false);

                 MemcachedNode qa=f.createMemcachedNode(sa, ch, bufSize);

                 int ops=0;

                 if(ch.connect(sa)) {    // throw exception, but the opened
Selector is not closed

                      getLogger().info("Connected to %s immediately", qa);

                      qa.connected();

                      assert ch.isConnected();

                 } else {

                      getLogger().info("Added %s to connect queue", qa);

                      ops=SelectionKey.OP_CONNECT;

                 }

                 qa.setSk(ch.register(selector, ops, qa));

                 assert ch.isConnected()

                      || qa.getSk().interestOps() == SelectionKey.OP_CONNECT

                      : "Not connected, and not wanting to connect";

                 connections.add(qa);

           }

           locator=f.createLocator(connections);

      }

Original issue reported on code.google.com by 70l...@gmail.com on 11 May 2009 at 9:08

[GoogleCodeExporter]

It's not clear to me what this bug is supposed to be.  What error are you 
referring to?

What do you think happens that's undesirable?  What would you prefer happen?

Original comment by dsalli...@gmail.com on 11 Nov 2009 at 7:42

• Changed state: Invalid

[GoogleCodeExporter]

The SocketChannel, since it's non-blocking, will not return errors when written 
to,
but only when read.  In that case, the disconnect is known and a reconnection 
attempt
is queued.

I clarified some of this in comments in 2.5

Original comment by ingen...@gmail.com on 1 Apr 2010 at 8:51