thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Diwaker Gupta (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (THRIFT-1195) Allow users to act on client connects/disconnects
Date Wed, 08 Jun 2011 23:09:58 GMT

    [ 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

Mime
View raw message