geronimo-dev mailing list archives

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

     Author: David Farb
    Created: Tue, 12 Oct 2004 1:47 PM

In the typical 'Command' pattern, the knowledge (code) to execute the command is inside the
command object. In Craig's terms, in the special packet that percolates through the system.
You could think of Craig's packet as a 'Command'. 

The problem I was refering to was encapsulating that much knowledge inside this 'failure command'.
Consider an HTTP server to an EJB server, to some database connectors, ... Passing a single
failure command through all of these objects, and having each of them be told how to fail
with the logic inside the 'failure command' object seems like too much to ask from the failure
command class. It needs to know about ALL the possible classes in the server, or all the classes
in the server need to implement the same interface (eg. the Failure interface...).

Using Craig's approach distributes the logic about how to fail into each of the packet processors,
while using the 'fail()' method approach removes the if (packet instanceOf ...) (or what ever)
logic in the packet processors. The 'fail()' method has the advantage of making the contract

View this comment:

View the issue:

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

   Reporter: David Farb

    Created: Tue, 12 Oct 2004 9:42 AM
    Updated: Tue, 12 Oct 2004 1:47 PM
Environment: All environments

Description: 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.

David Farb

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message