Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Java NIO channel never becomes readable

Reply
Thread Tools

Java NIO channel never becomes readable

 
 
nooneinparticular314159@yahoo.com
Guest
Posts: n/a
 
      03-17-2008
I have a Java NIO channel that is never readable. It does become
writable. I initially register it inside of an event loop as shown
below (I've only included the relevant snippets of code):

SelectionKey NextKey = (SelectionKey) KeyIterator.next();
if (NextKey.isAcceptable()) {
SocketChannel AcceptedChannel = null;
ServerSocketChannel ServerChannel = (ServerSocketChannel)
NextKey.channel();
AcceptedChannel = ServerChannel.accept();
AcceptedChannel.configureBlocking(false);
AcceptedChannel.register(ChannelSelector, SelectionKey.OP_READ |
SelectionKey.OP_WRITE);

and then I test to see if I can read and write:

if (NextKey.isReadable()) {
do fun reading stuff, like reading data from the channel
}

if (NextKey.isWritable()) {
do exciting writing stuff, like writing data to the channel!
}

While I do seem to be able to *write* to the channel, I am completely
unable to read, as the NextKey never becomes readable. I've tried
changing the registration of the channel at various points to read
only or write only, but that doesn't help. What I'm trying to do is
get two clients to talk to each other using NIO. What I have wound up
with is each client yelling at the other, but neither of them
listening to what the other says! What am I doing wrong here? Why
does NextKey never become readable? How can I fix it? I've checked
every Java NIO reference I can find, and nothing helps...

Thanks!
 
Reply With Quote
 
 
 
 
Mark Space
Guest
Posts: n/a
 
      03-17-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> only or write only, but that doesn't help. What I'm trying to do is
> get two clients to talk to each other using NIO. What I have wound up
> with is each client yelling at the other, but neither of them
> listening to what the other says! What am I doing wrong here? Why
> does NextKey never become readable? How can I fix it? I've checked
> every Java NIO reference I can find, and nothing helps...


Are you sure you write to the channel? Do you ever flush your writes?

Can you, for example, run telnet listening on the port you are using and
verify it receives what you write?

Can you read from this channel with out using NIO? It might be best to
start with something (test harness first!) easier to debug, then get NIO
working.
 
Reply With Quote
 
 
 
 
nooneinparticular314159@yahoo.com
Guest
Posts: n/a
 
      03-17-2008
On Mar 16, 11:10*pm, Mark Space <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > only or write only, but that doesn't help. *What I'm trying to do is
> > get two clients to talk to each other using NIO. *What I have wound up
> > with is each client yelling at the other, but neither of them
> > listening to what the other says! *What am I doing wrong here? *Why
> > does NextKey never become readable? *How can I fix it? *I've checked
> > every Java NIO reference I can find, and nothing helps...

>
> Are you sure you write to the channel? Do you ever flush your writes?
>
> Can you, for example, run telnet listening on the port you are using and
> verify it receives what you write?
>
> Can you read from this channel with out using NIO? *It might be best to
> start with something (test harness first!) easier to debug, then get NIO
> working.


That's a brilliant idea (telnet)! I'd never thought of trying that.
So I just did, and yes, the data is being written. I can also verify
that it DOES read data by typing a response in telnet. So what seems
to happen is that my program receives the data, but the channel never
gets set to read. So what could be causing this problem, and how do I
get it to read?

Thanks!
 
Reply With Quote
 
nooneinparticular314159@yahoo.com
Guest
Posts: n/a
 
      03-17-2008
On Mar 16, 11:10*pm, Mark Space <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > only or write only, but that doesn't help. *What I'm trying to do is
> > get two clients to talk to each other using NIO. *What I have wound up
> > with is each client yelling at the other, but neither of them
> > listening to what the other says! *What am I doing wrong here? *Why
> > does NextKey never become readable? *How can I fix it? *I've checked
> > every Java NIO reference I can find, and nothing helps...

>
> Are you sure you write to the channel? Do you ever flush your writes?
>
> Can you, for example, run telnet listening on the port you are using and
> verify it receives what you write?
>
> Can you read from this channel with out using NIO? *It might be best to
> start with something (test harness first!) easier to debug, then get NIO
> working.


Transmitting through Telnet, I get the following error, which I
suspect is the result of my sending bogus data through telnet, rather
than following the proper protocol:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at
BitTorrent.NetworkDataHandler.ReadMessageFromChann el(NetworkDataHandler.java:
412)
at BitTorrent.Main.main(Main.java:343)
Java Result: 1

I don't *think* that this is the cause of my not getting readable
channels though, since I've verified that the channel key is never
readable.

The channel does become readable when I transmit through telnet
though, and the client is clearly transmitting data when I connect
with telnet. What is happening here?

Thanks!
 
Reply With Quote
 
EJP
Guest
Posts: n/a
 
      03-17-2008
(E-Mail Removed) wrote:
> The channel does become readable when I transmit through telnet
> though, and the client is clearly transmitting data when I connect
> with telnet. What is happening here?

That indicates that your sending code is incorrect. If it's NIO code, it
needs to flip() the buffer before the write, compact() it afterwards,
and examine the count returned by the write() call. If that was zero,
you need to register the channel for OP_WRITE, and when it happens,
retry all that. If you *didn't* get zero, deregister OP_WRITE.
 
Reply With Quote
 
nooneinparticular314159@yahoo.com
Guest
Posts: n/a
 
      03-17-2008
Ok. I think I'm closer, but I'm still doing something slightly
wrong. My writing code looks like:

SetChannelForWritingOnly(); //This method does a
Channel.register(ChannelSelector,
//SelectionKey.OP_WRITE);


SendBuffer.flip();
BytesWrittenToChannel = Channel.write(SendBuffer);
SendBuffer.compact();
SetChannelForReadingOnly();

When I write to the channel, BytesWrittenToChannel is 0. So no bytes
are actually written. So I am registering the channel for writing
before, flipping the buffer before the write, compacting it
afterwards, and still getting 0. Huh?

Thanks!
 
Reply With Quote
 
nooneinparticular314159@yahoo.com
Guest
Posts: n/a
 
      03-17-2008
I should probably note that I have two buffers here: a send buffer and
a receive buffer. I always write to the sendbuffer, and I always read
from the receive buffer. I tried getting rid of the flip, and I was
suddenly able to write to the channel (although the other side still
doesn't read it!) The same data seems to get written to the channel
over and over again (possibly until the buffer on the other side fills
up?), after which, I get no ready channels...
 
Reply With Quote
 
nooneinparticular314159@yahoo.com
Guest
Posts: n/a
 
      03-17-2008
A further followup - when the data is written to the channel, the
position in the buffer does not appear to change. For example, when I
do:

BytesWrittenToChannel = Channel.write(SendBuffer);

The contents of SendBuffer before and after the write are identical.
The limit, capacity, and position do not change. If I do a
SendBuffer.flip or SendBuffer.clear(), it still doesn't change
anything in the SendBuffer! So the sendbuffer always contains the
data that I originally put into it, it keeps writing out, and it never
gets cleared. That data is received over my telnet connection if I
telnet to the program, but is never read in by my actual client, as
noted previously. Any idea why this might be happening? It's my
understanding that performing a write is supposed to consume the
contents of the buffer (or at least as much as is written), but this
doesn't seem to be happening.

Thanks!
 
Reply With Quote
 
nooneinparticular314159@yahoo.com
Guest
Posts: n/a
 
      03-17-2008
Another followup - I've recorded the transmissions using Ethereal (aka
Wireshark). Both clients are clearly transmitting to each other.
(After removing the Channel.flip and clear statements, the clients
transmit properly.) Ethereal shows that the transmissions sent are
exactly what should be sent. The problem is that the clients never
have OP_READ flag set for the channel. So this brings me back to my
original question - why doesn't OP_READ ever get set, and how can I
correct this?

Thanks!
 
Reply With Quote
 
EJP
Guest
Posts: n/a
 
      03-18-2008
(E-Mail Removed) wrote:
> The contents of SendBuffer before and after the write are identical.
> The limit, capacity, and position do not change. If I do a
> SendBuffer.flip or SendBuffer.clear(), it still doesn't change
> anything in the SendBuffer!


All that indicates that there is nothing to write, i.e. position = limit.

NB I think the result of a ByteBuffer.wrap() is already flipped for some
reason.

Re OP_READ, are you registering the channel for OP_READ?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Channel Switch in GO, can I do this with java.nio Jan Burse Java 10 11-06-2011 09:32 PM
and becomes or and or becomes and Stef Mientki Python 9 05-28-2011 02:04 PM
Java.NIO channel never becomes writable nooneinparticular314159@yahoo.com Java 6 03-17-2008 06:52 AM
Reversing Bit Order.. i.e. MSB becomes bit 0, LSB becomes bit 15 benn686@hotmail.com C++ 9 08-22-2007 12:13 AM
RAM - 2gb becomes 4gb becomes 2gb b Computer Support 10 04-27-2006 11:58 PM



Advertisments