Hi All,

 This problem has intrigued me for quite some time now. 
 I cannot reproduce it on any other platform other than
 RedHat Linux 6.x .

 I am working on a Java POP Server.
 I have a master thread, listening on a socket and 
 waiting for connection requests. It spawns a thread on
 receiving a request. The thread implements a session, it
 waits on the socket for input from the client. When
 the client sends a command It responds appropriately.

 I noticed that, if one session is active, and
 If I open another session with the Server, a SocketException 
 is thrown in the existing session.

 Reproduced below is the relevant stack trace: 
 java.net.SocketException: Interrupted system call
        at java.net.SocketInputStream.socketRead(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:90)
        at java.net.SocketInputStream.read(SocketInputStream.java:71)
        at java.io.InputStreamReader.fill(InputStreamReader.java:163)
        at java.io.InputStreamReader.read(InputStreamReader.java:239)
        at java.io.BufferedReader.fill(BufferedReader.java:137)
        at java.io.BufferedReader.read(BufferedReader.java:154)


 I am not using the -green option.
 I am performing clientSocket=serverSocket.accept() in the
 main thread & then passing clientSocket to the child.
 
 The behaviour of the problem is even more peculiar. It only
 happens once, when the first thread is spawned and waiting
 on clientInputStream.readLine() method for input and the 
 master thread is waiting on serverSocket.accept() method.
 When this situation is true - and as soon as a request is 
 received by the master thread, the existing session suffers 
 a SocketException.

 Once this is over, it never happens again, I can continue
 opening new sessions with the PopServer.

 Any words of advice ? Does someone have a solution ? 
 I could handle the exception and go back to attempt to
 reading from the clients Input stream, but when a 
 SocketException is thrown due to unpredicted behaviour
 from the clients side or due to some TCP error I will
 then go into a hard loop. So thats not what I want.
  
 Regards,
 Santosh Dawara.


----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to