Allow users to act on client connects/disconnects
-------------------------------------------------
Key: THRIFT-1195
URL: https://issues.apache.org/jira/browse/THRIFT-1195
Project: Thrift
Issue Type: New Feature
Components: Java - Library
Environment: Ubuntu 11.04, Sun JVM
Reporter: Diwaker Gupta
As it stands, the Java library doesn't provide any hooks to detect exactly when
a client got connected/disconnected. For many services, this information is
both useful and required for things like cleaning up state.
There are of course many possible ways to address this. Here are some thoughts
from my initial mail on the topic:
{noformat}
Suppose I have a stateful service and I'd like to clean up some state
when a client disconnects. IIUC, there's no straight forward way to do
this with Thrift. I'd love to hear what others have done in similar
situations.
I'm trying to figure out if there's a way to support this without
modifying Thrift core (this is all with the Thrift Java library):
* my first instinct was to extend TFramedTransport with a custom
factory that allows adding "listeners" that can be fired on a close.
Unfortunately it seems like TFramedTransport.close is either never
called, or not called when a client disconnects. The actual socket
close is wrapped up inside a TNonblockingSocket within the FrameBuffer
managed by TNonblockingServer. So this approach doesn't work.
* Since the client socket is generated by
TNonblockingServerSocket.accept, I next considered overriding
accemptImpl() in a custom ServerSocket. This poses other problems --
because much of the state in TNonblockingServerSocket is private, I
need to use super.acceptImpl() to obtain the TNonblockingSocket (or
reimplement everything). This in turn is not helpful because I then
need to wrap the returned TNonblockingSocket in another "forwarding
object" such that the listeners can be fired when the socket is
closed.
{noformat}
Unfortunately I did not find any way to do this without modifying Thrift
itself, hence this issue. After evaluating several different alternatives, I
decided to go with the least intrusive approach, which is implemented in the
attached patch. Basically users can add open/close handlers as part of the Args
supplied to TNonblockingServer. The server code then invokes the callbacks when
appropriate. I realize this approach is not perfect so I'm eager to get some
feedback and hear some alternatives.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
