[jira] [Updated] (THRIFT-1195) Allow users to act on client connects/disconnects

["Diwaker Gupta (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Diwaker Gupta updated THRIFT-1195:
----------------------------------

    Attachment: THRIFT-1195-v0.patch

> 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