Problem with ServerSocket.accept
Hi, I'm from Italy so I apologize for my English.
The problem is this, I created a separated Thread to listen the connections that come from the various clients, when it receive a connection it creates a new Thread to manage the connection.
The problem is that I need to stop the Thread (the one that look for new connetions), whenever I need it, but how can i do it if the method ServerSocket.accept(); stop the execution of the thread.
The listener of new connections extends Thread and this is the run method overridden.
publicvoid run(){
ServerSocket ss;
Server myServer;/* Another class that extends Thread to manage the connection */
while (true){
try{
ss =new ServerSocket(port, queueLength);
Socket sd = ss.accept();
myServer =new Server(sd);
myServer.start();
}
catch (IOException e){
}
}
}
[1420 byte] By [
nick1080a] at [2007-10-2 21:09:59]
[code]
public void run() {
ServerSocket ss;
Server myServer;
/* Another class that extends Thread to manage the connection */
while (true) {
try {
ss = new ServerSocket(port, queueLength);
Socket sd = ss.accept();
myServer = new Server(sd);
myServer.start();
}
catch (IOException e) {
}
}
}
[\code]
First of all this code is unworkable - only first connection will be accepted. You should move server socket creation out from your loop. As for thread stopping - you can just close your server socket somethere or use setSoTimeout( ) to set timeout and check exit condition after each timeout exception.
Great !!!!
I introduced the setSoTimeout and now I can do exactly what I need.
I don't understand why you said the code was unworkable, and only the first connection would be accepted, the server was already working with many connections from clients. However I also don't understand what you mean when you say that I have to check the exit condition.
However really really thanks (Grazie mille).
> I don't understand why you said the code was unworkable
Ahh, sorry, not completely unworkable but very bad designed :)
Add error messages output into catch section and you'll see number of exceptions during working. You recreate server socket after each client connection - completely bad idea. You should make some rewriting.
> However I also don't understand what you mean when you say that I have to check the exit condition.
Nevermind. "now I can do exactly what I need." - this is main result :)
I know this is an old thread but I had the same question so I thought I'd just attach it to this.
I want to be able to start and stop my ServerSocket on demand and I need a way to unblock it's thread once it's "accepting."
I can think of two ways to do this:
1. The solution presented in this thread. This is clearly a misuse of Exceptions however so I decided against it.
2. Set the exit condition, create a dummy client socket to connect to the server, then test for the exit condition.
So is there a better way?
Why do you think it's a 'clearly misuse of exceptions'?
ejpa at 2007-7-13 23:55:56 >
An exception is an "exceptional event", an error in a program that should never(you hope) happen.
No, that's an Error or a RuntimeException. Other Exceptions happen all the time. For instance, EOFException. And there is no other solution. You are either going to provoke a SocketException: socket closed if you close the ServerSocket or a SocketTimeoutException if you use the timeout & flag system.
ejpa at 2007-7-13 23:55:56 >
First, as I stated above you can do it without using the Java Exception mechanism incorrectly:
// Server thread
...
while(!stopServer){
socket = serverSocket.accept();
...
}
...
// another thread that wants to cause the server to stop
...
stopServer = true;
dummySocket.connect(<servers address and port>);
... //dummySocket and socket agree to disconnect politely
Second, you're wrong about exceptions. While using exceptions as you describe works, it's just plain bad design. You're creating odd jumps in your code that amount to glorified goto statements and creating extra exit points that can mask potential bugs.
BTW according to Sun: "Definition: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions."
This seems to be pointless purity to me. I agree completely with Sun, but I view closing the server as an exceptional condition: it only happens once, and the normal program flow is to keep accepting connections. You have to handle IOExceptions from that loop somewhere anyway, and any IOException from accept() apart from a timeout indicates that the server socket is of no further use, so what extra exit points are being created?
And the other issue is that closing the socket will always work. Attempting a dummy connection requires its own try/catch handling: and what are you going to do in the catch block, i.e. if you can't form the dummy connection?
ejpa at 2007-7-13 23:55:56 >
> This seems to be pointless purity to me. I agree
> completely with Sun, but I view closing the server as
> an exceptional condition: it only happens once, and
> the normal program flow is to keep accepting
> connections. You have to handle IOExceptions from
> that loop somewhere anyway, and any IOException from
> accept() apart from a timeout indicates that the
> server socket is of no further use, so what extra
> exit points are being created?
>
> And the other issue is that closing the socket will
> always work. Attempting a dummy connection requires
> its own try/catch handling: and what are you going to
> do in the catch block, i.e. if you can't form the
> dummy connection?
Why is the server only closed once? There are plenty of reasons to need to stop and restart it. Anything you design into your program is not exceptional it is normal program flow. I'm not sure what your argument is? Because you have to write catch statements anyway you might as well use that code? Those catch statements are for releasing resources, trying to recover, printing an error log, etc.
It is a purity issue, but I disagree that it is pointless. Its about being able to read and maintain code, and having a logical flow from one statement to the next. I wont get in to a history lesson but goto statements were abandoned and not implemented in Java for good reason.
I also wont say that you are wrong as you simply stated a programming preference. But that preference is built on the believe that misusing exceptions is not a big deal. I just hope any junior programmers reading this and especially anyone thinking of taking the SCJD exam realize that exceptions are designed so that if one occurs, something bad/unexpected/needing to be recovered from happened.
Actually you did say I was wrong, in reply #9. I'm glad you've now retracted that.
But I don't need any education as to Dijkstra's goto considered harmful letter to the ACM in 1968 either, which I first read in 1971, or the omission of 'goto' from Java, thank you very much. Not that it's relevant. You can't characterise a method call in one thread which causes an exception in another thread, while the first thread continues on, as a goto however hard you try.
You haven't addressed my point about the dummy connection being unreliable.
ejpa at 2007-7-13 23:55:56 >
Sorry if I offended you. I said you were wrong about exceptions but I guess it would be more accurate to say your opinion on exceptions differs from generally accepted good programming practice and the intentions of the language designers.
As for stopping the server by flagging then connecting with another socket to stop the blocking caused by accept, I'm not exactly sure what part of that you're saying is unreliable. The fact that it may cause an exception?
As for the goto comparison, how else do you characterize an unconditional jump in code from one location to another?
Message was edited by:
luchador
What is unreliable is that the dummy TCP/IP connection, being an operation subject to errors and therefore exceptions itself, may not complete. I know it's a local connection but there are still some local conditions whereby the connect operation can fail, such as the backlog queue being full, or lack of OS buffers, or the NIC going down, ... Not too hard to think of a few more if necessary.
You can't characterize any interaction between two threads as a goto, sorry, and certainly not as an unconditional jump. I would characterize an exception being thrown as an interrupt myself, especially as the code which causes it isn't anything remotely resembling a 'goto' itself. And this is by no means the only time that a programmer might cause an exception to be thrown. EOFException is another one, no way to avoid it, and so is a timeout exception. Again it's not too difficult to come up with many more. Thread.interrupt() is another one.
And just continuing to assert one idea of 'good programming practice' as being universal doesn't really advance the argument. It's not universal with me. I have my own ideas of good programming practice too, but if closing the server socket seemed like the best idea for other reasons I wouldn't necessarily let any style considerations deter me, even my own.
OTOH I don't use exceptions for flow control within the same method, which is what the 'good programming practice' you're probably referring to is really about.
ejpa at 2007-7-13 23:55:56 >
