Thread: [Asterisk-java-devel] Regarding accept() call IOException
Brought to you by:
srt
From: Shivram u <shi...@gm...> - 2006-08-11 07:26:52
|
Hi, In fastagi/DefaultAGIServer.java i had a question w.r.t exception handling of the accept call. How does java work in the statement while ((socket = serverSocket.accept()) != null) I assume that it throw an exception and gets handled by the exception handler. rather than hitting the check for socket being null. If my assumption is correct, we hit the catch and then the finally statement where we close the server socket. But shouldnt we just wait for the next client connection when the accept call fails Something like While (1) { try { socket = accept(); } catch IOException() { continue; /* loop back for the next client connection */ } Below is the piece of code in question Best Regards, Shivram U try { while ((socket = serverSocket.accept()) != null) { logger.info("Received connection."); connectionHandler = new AGIConnectionHandler(socket, mappingStrategy); pool.addJob(connectionHandler); } } catch (IOException e) { // swallow only if shutdown if (!die) { logger.error("IOException while waiting for connections.", e); throw e; } } finally { if (serverSocket != null) { try { serverSocket.close(); } catch (IOException e) { // swallow } } serverSocket = null; pool.shutdown(); logger.info("AGIServer shut down."); } |
From: Stefan R. <sr...@re...> - 2006-08-11 09:04:29
Attachments:
signature.asc
|
Hi, Shivram u wrote: > How does java work in the statement > while ((socket =3D serverSocket.accept()) !=3D null) >=20 > I assume that it throw an exception and gets handled by the exception > handler. rather than hitting the check for socket being null. You are right, the null check is not needed here. I'll change it for 0.3.= > If my assumption is correct, we hit the catch and then the finally > statement where we close the server socket. correct - at least we try closing the serversocket. > But shouldnt we just wait for the next client connection when the accep= t > call fails If the server socket has a problem that is usually due to something as severe as the socket being shutdown. I doubt it is usefull to try to reuse it after it threw an exception. If there are IOExceptions on the client sockets (i.e. client just connects and disconnects) we already do continue with the next client. Did you encounter any problems with the code? =3DStefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... |
From: Shivram u <shi...@gm...> - 2006-08-11 10:42:00
|
Hi Stefan, > But shouldnt we just wait for the next client connection when the accept > > call fails > > If the server socket has a problem that is usually due to something as > severe as the socket being shutdown. I doubt it is usefull to try to > reuse it after it threw an exception. > If there are IOExceptions on the client sockets (i.e. client just > connects and disconnects) we already do continue with the next client. > > Did you encounter any problems with the code? I havent encountered any problems with that code. I browsing the code came across this. Im not that experienced in java. I assumed that the accept() call would be similar to a C lib accept() call, where an accept can fail if the client aborted the connection(ECONNABORTED) I tried searching the web for the reasons why an IOException could be generated for a socket accept(), but havent found any. Best Regards, Shivram U |
From: Stefan R. <sr...@re...> - 2006-08-11 17:48:33
Attachments:
signature.asc
|
Shivram u wrote: > I havent encountered any problems with that code. I browsing the code > came across this. Im not that experienced in java. I assumed that the > accept() call would be similar to a C lib accept() call, where an accep= t > can fail if the client aborted the connection(ECONNABORTED) > =20 > I tried searching the web for the reasons why an IOException could > be generated for a socket accept(), but havent found any. Yes, you are right. There is not much documentation but it seems indeed that most exceptions are recoverable. I changed the code to check for the die flag and break only if we explicitly closed the socket by shutdown(). You can see the changes at http://asterisk-java.org/fisheye/browse/repos/asterisk-java/trunk/src/mai= n/java/org/asteriskjava/fastagi/DefaultAgiServer.java?r1=3D492&r2=3D538#s= eg26 Thanks! Stefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... Jabber: sr...@ja... |