[
https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046273#comment-13046273
]
Diwaker Gupta commented on THRIFT-1195:
---------------------------------------
Sure. As long as there's a reasonable hook, I'm not particularly attached to a
specific implementation.
> 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
> Attachments: THRIFT-1195-v0.patch
>
>
> 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
