Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / First Aid / March 2006

Tip: Looking for answers? Try searching our database.

Socket (and Selector) seems to freeze after first data stream

Thread view: 
Hal Vaughan - 16 Mar 2006 20:44 GMT
I posted a related question a few days ago, along with code, and did not get
any responses.  So here goes a different version.  I can post code, but
there's a lot, so I can also post only specific sections.

I'm working on a port forwarder and the first step is to get the local port
to listen to all incoming data.  I've created a ServerSocket and a
ServerSocketChannel, then I've created a Selector and registered the
ServerSocketChannel with a Selector for OP_ACCEPT.  Then I go into a loop
where I wait on the Selector.select() function.  I've tried this with it
waiting forever and with it waiting 50 milliseconds, then, if nothing,
waiting again (which also leaves time to check the stopForwarding flag).

I have a Perl program I'm using to send data to the ServerSocket.  For now
I'm just sending text, but in the long run, of course, it could be any kind
of binary data.  The Perl program sends one message, then sleeps for a
second, then goes into a loop where it sends a message, sleeps a second,
then sends another message for 10 times.

In the Java program, Selector.select() picks up the first data coming in to
the ServerSocket, the SelectionKey is registered, it is acceptable, and I
create a Socket and SocketChannel, then register the SocketChannel (for
OP_READ) with the same Selector the ServerSocketChannel is registered with.
It does see the first message sent to the socket and receives it properly.
I make sure I cancel the keys, both after the Socket is created AND after
the read operation.  Then the program *should* go to the top of the loop,
wait again and receive the next line of data from the Perl program through
the socket.

This is where it stops working and it seems dead.  Println statements show
the socket is still alive, not closed, not even half-closed, but that 2nd
stream of data is NEVER detected.  The Selector never responds to any new
readable operation.

As I said, I've posted something similar with code and didn't get any
replies.  I've used, as close as possible, the code in different tutorials
and examples I've seen online, but there's nothing focusing on this.  After
the first data stream, then a pause, neither the Socket or Selector
responds again.  I've tried re-running the Perl program to see if it would
open a new socket again, and it doesn't.

What could make a socket or selector seem to die or freeze after its first
burst of data?  My best guess is this is a Selector problem, but I'm doing
everything the way I've seen in examples.  I have some questions, but I
don't if any are helpful, or just me grabbing at straws:

Is there a problem registering more than one SocketChannel with the same
Selector?

Other than key.cancel() is there something else that must be done to make
sure the Selector is ready for the "next round?"

Why doesn't the ServerSocket want to create more sockets each time a new
message from my Perl program comes in?

Any suggestions or help are welcome.

Thanks!

Hal
Gordon Beaton - 17 Mar 2006 08:49 GMT
> Is there a problem registering more than one SocketChannel with the
> same Selector?

There would be little point in using a Selector if that were the case!

> Other than key.cancel() is there something else that must be done to
> make sure the Selector is ready for the "next round?"

You should be removing the key from the selected-key set "by invoking
the set's remove method or by invoking the remove method of an
iterator obtained from the set" (from the Selector documentation).

Instead you are *cancelling* the key, which I believe is causing it to
be deregistered on the next call to select().

/gordon

Signature

[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e

Hal Vaughan - 17 Mar 2006 19:15 GMT
>> Is there a problem registering more than one SocketChannel with the
>> same Selector?
>
> There would be little point in using a Selector if that were the case!

That's what I thought, but just wanted to check.

>> Other than key.cancel() is there something else that must be done to
>> make sure the Selector is ready for the "next round?"
[quoted text clipped - 5 lines]
> Instead you are cancelling the key, which I believe is causing it to
> be deregistered on the next call to select().

Okay. that's a MAJOR piece of help here.  It makes me wonder if the guy that
wrote the article with that example ever actually ran his code.  Part of
his loop included selectionKey.cancel() at the bottom end, so any time a
key was used, it was canceled.  Funny thing is he used Iterator.remove() at
the top of the loop, then did everything else.  He didn't explain clearly
that remove() was to clear the key -- I just thought it was an Iterator
thing I had never seen in any examples.

I've tested it and it at least receives multiple signals from the Perl test
program now.  I have a LOT of debugging crap to remove so I can work on it
now.  I guess if there are more problems, I'll be posting them!

Thanks -- that was a key point that I really needed!

Hal

 
> /gordon

(Sorry for the e-mail copy -- my reply buttons got reversed in Kontact and I
hit the wrong one!)


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.