[jira] Commented: (GERONIMO-373) Percolate errors from SocketProtocol up the stack

[de...@geronimo.apache.org]

The following comment has been added to this issue:

     Author: Craig Johannsen
    Created: Tue, 12 Oct 2004 10:55 AM
       Body:
In a server I recently designed, we assumed IOExceptions were terminal errors, as far as the connection is concerned.  We used a specially marked "packet" (actually, just an object), which was sent up the stack when an IOException or other Exception was detected in the SocketServer.  This was used by the up-side of each layer (or protocol) in the stack as a signal that it must do its teardown procedure (e.g., unlink from previous element in stack).  At the top of the stack, the special packet was turned around and sent down the stack as a signal to the down-side of each layer that it must do its teardown procedure.

At the top of the stack, the signal also would propagate via a queue to other objects that needed to know about it.  For example, the client proxy object needed to write the online/offline status to a database record and then inform group conversation and private conversation objects that the client was not there any more.

An advantage of this approach is that the interface is kept very simple and the signal can propagate across queues or whatever is in the stack without much concern for how the stack is implemented.  However, if there are queues, the signal could get stuck in an outbound queue, for example, and fail to make the complete round trip.  We avoided this problem by having a combination of queued and unqueued paths up and down the stack.  The main flow was just a series of function calls: "up" to send a parameter up the stack and "down" to send a parameter down the stack.  The teardown signal object got special handling at each level, which actually was a disadvantage, since it required an "if" statement to check the type of signal object, which imposes a small overhead on every message.

We didn't assume that the creator of the stack needs to do the teardown.  The stack knew how to tear itself down.  You may want to carefully examine your assumption about this.

There are other equally effective ways of accomplishing the same thing.  This was just one that seemed to work well.
---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/GERONIMO-373?page=comments#action_53947

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-373

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: GERONIMO-373
    Summary: Percolate errors from SocketProtocol up the stack
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: Apache Geronimo
 Components: 
             general

   Assignee: 
   Reporter: David Farb

    Created: Tue, 12 Oct 2004 9:42 AM
    Updated: Tue, 12 Oct 2004 10:55 AM
Environment: All environments

Description:
o.a.g.network.protocol.SocketProtocol does not percolate a client error or exception up the protocol stack when the client disconnects.

When serviceRead in SocketProtocol gets an IOException or some other error, the socketChannel is closed, but the up protocol is not informed.

Calling the teardown method of the up protocol is probably not an appropriate way to handle these exceptions. The teardown method should be called by the creator of the protocol stack. Instead, the exception/error should percolate up the protocol stack to the creator (via some sort of callback mechanism) which should then remove the stack and associated information from the server environment. 

Either a new method reserved for this could be defined in the Protocol interface (up.handleException(Throwable t)) or sending a null, empty or specially marked packet via up.sendUp(UpPacket upPacket) could be implemented.

Since in most cases the server is waiting for a client response, if the client goes away, server components need to be informed of this fact so the server side objects can be cleaned up. There is usually no way to recover these objects, hence they are a memory leak.

I would be happy to submit a fix for this, but I would appreciate feedback on the most appropriate way to do it.

Thanks
David Farb







---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira