Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <1460042921.1106413580699.JavaMail.jira@ajax.apache.org>
Date: Sat, 22 Jan 2005 18:06:20 +0100 (CET)
From: "Alan Cabrera (JIRA)" <dev@geronimo.apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Closed: (GERONIMO-373) Percolate errors from SocketProtocol up
 the stack
In-Reply-To: <1530276943.1097599431235.JavaMail.apache@nagoya>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/GERONIMO-373?page=history ]
     
Alan Cabrera closed GERONIMO-373:
---------------------------------

    Resolution: Fixed

Network/remoting code has been assimilated into ActiveIO.  David Farb has been invited to join the effort.

> Percolate errors from SocketProtocol up the stack
> -------------------------------------------------
>
>          Key: GERONIMO-373
>          URL: http://issues.apache.org/jira/browse/GERONIMO-373
>      Project: Apache Geronimo
>         Type: Improvement
>   Components: general
>  Environment: All environments
>     Reporter: David Farb
>     Assignee: Alan Cabrera
>  Attachments: Geronimo-373.zip
>
> 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

-- 
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