Need some clarification and/or help with java NIO sockets

[HDSkiFreak]

Greetings:

I'm having a bit of a problem with java NIO sockets. I've tried
searching around for a similar problem, but I haven't found much.

I' using the 1.4.2 JDK under Linux RH 9. I'm working on an application
that needs to establish a TCP connection asyncrhonously, so I cannot
block while the connection is being established. I also need to assign
a limit (connection timeout) to the operation, and retry if needed.

All communication with the tcp mulde is async, so I thought of using
NIO non-blocking (NB) sockets and select().

Here's basically the gist of it:

I decide to do the following:

long timeout = 1000;
InetAddress addr = new InetSocketAddress("127.0.0.1", 1026);
SocketChannel sc = SocketChannel.open();
sc.socket().connect(addr, timeout);

Then use the channel as prescribed:

ByteBuffer buf = ByteBuffer.allocate(1024);
sc.write(buf);


And close it as prescribed:

sc.close();


With that in mind, If I encapsulate all those operation iside a worker
thread, I find that the socket handle is never released, I my app
leaks handles like crazy. Eventually, the VM runs out of handles, and
the whole thing comes crashing down fast.

I tried calling close() on the socket (since I call connect on the
socket), like this:

// Close operation
sc.socket().close();
sc.close();

But this had no effect. The handles were still leaking.


Now, if I change the connect logic to use:

sc.connect(addr)

instead of:

sc.socket().connect(addr, timeout);

The application does not leak handles, and it works fine. Naturally, I
have now lost the (easy) ability if connecting with a timeout.


My question is: Is this a known problem? I understand that I can
simulate the "connect with a timeout" situation using a NB socket
channel coupled with a select() call, but I'm not sure that is the
best course of action.

Your feedback is greatly appreciated.

Best Regards,

HDSkiFreak

 

[Yu SONG]

Greetings:

I'm having a bit of a problem with java NIO sockets. I've tried
searching around for a similar problem, but I haven't found much.

I' using the 1.4.2 JDK under Linux RH 9. I'm working on an application
that needs to establish a TCP connection asyncrhonously, so I cannot
block while the connection is being established. I also need to assign
a limit (connection timeout) to the operation, and retry if needed.

All communication with the tcp mulde is async, so I thought of using
NIO non-blocking (NB) sockets and select().

Here's basically the gist of it:

I decide to do the following:

long timeout = 1000;
InetAddress addr = new InetSocketAddress("127.0.0.1", 1026);
SocketChannel sc = SocketChannel.open();
sc.socket().connect(addr, timeout);

Then use the channel as prescribed:

ByteBuffer buf = ByteBuffer.allocate(1024);
sc.write(buf);


And close it as prescribed:

sc.close();


With that in mind, If I encapsulate all those operation iside a worker
thread, I find that the socket handle is never released, I my app
leaks handles like crazy. Eventually, the VM runs out of handles, and
the whole thing comes crashing down fast.

I tried calling close() on the socket (since I call connect on the
socket), like this:

// Close operation
sc.socket().close();
sc.close();

But this had no effect. The handles were still leaking.


Now, if I change the connect logic to use:

sc.connect(addr)

instead of:

sc.socket().connect(addr, timeout);

The application does not leak handles, and it works fine. Naturally, I
have now lost the (easy) ability if connecting with a timeout.


My question is: Is this a known problem? I understand that I can
simulate the "connect with a timeout" situation using a NB socket
channel coupled with a select() call, but I'm not sure that is the
best course of action.

Your feedback is greatly appreciated.

Best Regards,

HDSkiFreak

Yes, I experienced the same problem.

I recommend you to use select() call or other customized timeout class for
the timeout, and use methods in the channel class for NB connect and NB
read&write.

 

[HDSkiFreak]

Thanks for the reply. I was hoping that I didn't have to do that,
although is pretty trivial to emulate.

I ran some tests using this approach, and it seems to have solved the
problem.

Thanks again,

HDSkiFreak