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

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

    [ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289707#comment-13289707 ] 

Hudson commented on THRIFT-1195:
--------------------------------

Integrated in Thrift #496 (See [https://builds.apache.org/job/Thrift/496/])
    THRIFT-1195 Allow users to act on client connects/disconnects
HIVE-3067 Shutdown HiveMetaStore on client disconnect or timeout
HIVE-3057 metastore.HiveMetaStore$HMSHandler should set the thread local raw store to null in shutdown()

Patch: Dragan Okiljevic (Revision 1346566)

     Result = FAILURE
roger : http://svn.apache.org/viewvc/?view=rev&rev=1346566
Files : 
* /thrift/trunk/lib/java/src/org/apache/thrift/server/AbstractNonblockingServer.java
* /thrift/trunk/lib/java/src/org/apache/thrift/server/ServerContext.java
* /thrift/trunk/lib/java/src/org/apache/thrift/server/TServer.java
* /thrift/trunk/lib/java/src/org/apache/thrift/server/TServerEventHandler.java
* /thrift/trunk/lib/java/src/org/apache/thrift/server/TSimpleServer.java
* /thrift/trunk/lib/java/src/org/apache/thrift/server/TThreadPoolServer.java
* /thrift/trunk/lib/java/test/org/apache/thrift/test/TestServer.java

                
> 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
>            Assignee: Roger Meier
>         Attachments: Java_Thrift_TestServer_patch_to_demonstrate_ServerEventHandler_functionality.patch, THRIFT-1195-v0.patch, patch_to_add_TServerEventHandler_to_java_servers_v1.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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira