geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d..@geronimo.apache.org
Subject [jira] Commented: (GERONIMO-373) Percolate errors from SocketProtocol up the stack
Date Tue, 12 Oct 2004 21:07:51 GMT
The following comment has been added to this issue:

     Author: Craig Johannsen
    Created: Tue, 12 Oct 2004 2:07 PM
       Body:
I think there are some potential advantages to keeping the contract explicit:
1.)  Simpler logic in each protocol layer
2.)  More efficient execution

The disadvantages seem fairly minor:
1.)  Ever so slightly more complex interface.
2.)  Possibly, the need for an additional object to manage the teardown.
     If not careful, such an object could be a bottleneck when a large
     number of clients are disconnecting all at once.  Which thread is
     it going to execute in?  What to do about outbound messages coming
     down the stack while the teardown is in progress?

However, it raises the issue of how to propagate the fail signal.  Part of the contract must
be that up-side layer must propagate the fail signal up and each down-side layer must propagate
the signal down, or, alternatively, some manager object must look after the propagation through
the stack (i.e., iterate through each layer in the stack and call the fail function).  The
same object could have some knowledge of how to propagate the fail signal to other objects
if that is desired.

In geronimo, the ProtocolStack object already does this sort of thing, or at least knows how
to navigate the components of the stack and tell each one to do some operation, though teardown
has no implementation.  Perhaps a partial solution is to use teardown as the fail signal and
some implementation in ProtocolStack, something like the following:
    public void teardown() throws ProtocolException {
        for (int i = 0; i < this.size(); i++) {
            Protocol protocol = (Protocol) this.get(i);
            protocol.drain(); // Should set to a non-running state.
            protocol.clearLinks();
            protocol.teardown();
        }
    }

---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/GERONIMO-373?page=comments#action_53963

---------------------------------------------------------------------
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 2:07 PM
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


Mime
View raw message