[
https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dragan Okiljevic updated THRIFT-1195:
-------------------------------------
Attachment: patch_to_add_TServerEventHandler_to_java_servers_v1.patch
The following patch adds Thrift Java servers the ability to add customized
handlers for start/connect/disconnect/process events by implementing
TServerEventHandler interface.
This functionality already exists for C++ servers and is implemented in a same
fashion.
After creating your handler, you just need to register it using added
TServer.setServerEventHandler(TServerEventHandler) method before starting the
server.
Current patch is made against today's trunk revision, and it works for blocking
server implementations: TSimpleServer and TThreadedPoolServer, but still not
for TNonblockingServer (trying to add the handler throws an unsupported
exception).
> 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,
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
