The situation is that the server (Geronimo in the up protocol) is waiting for input from the client. The client disconnects. SocketProtocol gets an IOException in serviceRead, but the error never percolates up the protocol stack, so the server sits and waits for ever.
> -----Original Message----- > From: Alan D. Cabrera [mailto:[EMAIL PROTECTED] > Sent: Monday, October 11, 2004 10:00 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: o.a.g.network.protocol.SocketProtocol and Error Recovery > > > I think that it needs an error state so that when someone tries to > access the dead protocol, it will throw a ProtocolException. Remember, > that when you are in a serviceRead you're not in the stack, per se. The server will never access the protocol, the protocol is waiting for a message (request) from the client. > > I don't think that we need any changes to the Protocol interface but I'm > interested in what you were thinking. > > > Regards, > Alan > > > -----Original Message----- > > From: David Farb [mailto:[EMAIL PROTECTED] > > Sent: Monday, October 11, 2004 9:45 PM > > To: Dev > > Subject: o.a.g.network.protocol.SocketProtocol and Error Recovery > > > > > > o.a.g.network.protocol.SocketProtocol does not percolate a client > error > > up the protocol stack when the client disconnects. For example, when > > serviceRead gets an IOException, the socketChannel is closed, but > > the up protocol is not informed. > > > > Is this by design? If so how is the up protocol to find out that the > > client > > has gone away? > > > > If this is an error, I can probably come up with a solution, but I > would > > be interested in opinions on how best to fix it, as it probably will > > require > > changes to the o.a.g.network.protocol.Protocol interface. > > > > Thanks > > David Farb > > > >
