Bad ServerSocket ! Listen! Listen! Listen!

[Donny]

ok .. just wanted some help .. ( throw new YeahWeKnowException() !!)

after extensive 're-search' , i've found out that a ServerSocket is
supposed to go back to listening after starting a new Thread to handle
the returned Socket...

here's the problem-code:

ServerSocket serv_sock = new ServerSocket(80);
while(true) {
Socket temp = serv_sock.accept();
new ServiceManager(temp).start(); //code is blocking here!!
}


ServiceManager is a class that extends Thread.
what is happening is that code blocks at the area shown... the while
loop is not continued, until the socket that is passed to the
ServiceManager is closed...
the serv_sock doesn't go back to listening...

.... could anyone please throw some light on the matter..??

thanks in advance....

 

[kjc]

#1, the ServerSocket doesn't start a new thread, you do.
#2, The code is blocking because a) you don't have the thread properly
coded, and b) in your thread, your're waiting for I/O

 

[Steve Horsley]

ok .. just wanted some help .. ( throw new YeahWeKnowException() !!)

after extensive 're-search' , i've found out that a ServerSocket is
supposed to go back to listening after starting a new Thread to handle
the returned Socket...

here's the problem-code:

ServerSocket serv_sock = new ServerSocket(80);
while(true) {
Socket temp = serv_sock.accept();
new ServiceManager(temp).start(); //code is blocking here!!
}


ServiceManager is a class that extends Thread.
what is happening is that code blocks at the area shown... the while
loop is not continued, until the socket that is passed to the
ServiceManager is closed...
the serv_sock doesn't go back to listening...

... could anyone please throw some light on the matter..??

thanks in advance....

I think you should have a good look at the ServiceManager constructor,
as I think this is where the problem is. I say that because I don't
think Thread.start() ever blocks for a significant time. You could
try breaking it down like this to prove the point:

ServerSocket serv_sock = new ServerSocket(80);
while(true) {
System.out.println("Waiting to accept...");
Socket temp = serv_sock.accept();
System.out.println("Creating ServiceManager...");
ServiceManager sm = new ServiceManager(temp);
System.out.println("Starting service manager...");
sm.start();
}

Steve

 

[Donny]

Thanks Steve and kjc for throwing some light on the matter..

Some doubts about the blocking on I/O part ....

< for reference..>

ServerSocket serv_sock = new ServerSocket(80);
while(true) {
Socket temp = serv_sock.accept();
new ServiceManager(temp).start(); //code is blocking here!!
}


In my program, each new ServiceManager waits on unique queues, for a
message that's relevant to the particluar connection it is initialized
with..
I wanted them all to wait independent of each other..
would this cause the whole while loop to lock??

meanwhile, i'll try the suggestions.. thanks again..

 

[kjc]

Be sure that the waiting on the Queue part happens AFTER the thread has
forked. It sounds like you are doing this BEFORE the thread has started.

 

[Donny]

Be sure that the waiting on the Queue part happens AFTER the thread has
forked. It sounds like you are doing this BEFORE the thread has started.

Boing!!
No progress ...

I've checked the code.. and the waiting on the queue happens only
in the run() method.. it is called only *after* the thread is invoked,
right?

beats me...!

 

[Steve Horsley]

Boing!!
No progress ...

I've checked the code.. and the waiting on the queue happens only
in the run() method.. it is called only *after* the thread is invoked,
right?

beats me...!

Did you split this line:

new ServiceManager(temp).start();

into two lines to prove whether it was the constructor or the
call to start() that was blocking? I still think it must be the
constructor rather than start(). Just looking at the code won't
help much.

Maybe the constructor is trying to acquire a lock that another
thread is holding.

Steve

 

[kjc]

I have to agree with one of the other posters.
I strongly believe that it is happening in the ctor of your class.
Can you post some code.

 

[tom bender]

Show us your ctor.

Boing!!
No progress ...

I've checked the code.. and the waiting on the queue happens only
in the run() method.. it is called only *after* the thread is invoked,
right?

beats me...!

 

[Donny]

Well.. i did try adding the println's before and after the
contructor..
It is getting called fine..
the blocking is on the start() call...

However, here's the constructor:

public ServiceManager(Socket socket, /*..some app specific variables
*/ )throws Exception
{
this.socket = socket;
this.input = socket.getInputStream();
this.output = socket.getOutputStream();
br =
new BufferedReader(new InputStreamReader(input));
/*
* some Strings and int's initialized..
*/

}

would the creation of Input and OutputStreams block? No chance, i
guess..
what about the buffered reader? it's not a static class member or
anything...

any clues? thanks for all the help!

 

[kjc]

Wait, are you subclassing thread or implementing Runnable ??
Also, move all this code into your run(){} method.

 

[Steve Horsley]

Well.. i did try adding the println's before and after the
contructor..
It is getting called fine..
the blocking is on the start() call...

You haven't overridden start() have you?
If not, then the only other idea that I have is that maybe
your newly started thread is diving into an infinite loop
and you are on a machine that doesn't do preemptive task
switching.

Steve

 

[Andrew Thompson]

You haven't overridden start() have you?

A good answer to that is an SSCCE, then the
folks that are experienced at this stuff
could stop guessing..
<http://www.physci.org/codes/sscce.jsp>

 

[Donny]

Ok ... guys thanx for your time and your suggestions...
I think i'll rewrite the entire code from scratch, and prepare an
SSCCE ...
i realise how little material you had to work on ...

thanks for the write-up Andrew..
it's an essential part of posting etiquette i feel .. but sometimes
people get turned away by lots of code.. that's why i didn't include
them.

anyways... brb!