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
