Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
Ubuntu 11.04, Sun JVM
-
Patch Available
Description
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:
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.
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.