You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Diwaker Gupta (JIRA)" <ji...@apache.org> on 2011/06/03 19:49:47 UTC
[jira] [Created] (THRIFT-1195) Allow users to act on client
connects/disconnects
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
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
[jira] [Assigned] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Roger Meier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roger Meier reassigned THRIFT-1195:
-----------------------------------
Assignee: Roger Meier
> 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
[jira] [Commented] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Ashutosh Chauhan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285109#comment-13285109 ]
Ashutosh Chauhan commented on THRIFT-1195:
------------------------------------------
Whats the status of this issue? I work on Hive project and we can also make use of this functionality if available. Also, will this hook/function will be called only if client explicitly closes the connection or will it also be called when client goes idle and connection is timed-out on server?
> 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: 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
[jira] [Updated] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Dragan Okiljevic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dragan Okiljevic updated THRIFT-1195:
-------------------------------------
Attachment: Java_Thrift_TestServer_patch_to_demonstrate_ServerEventHandler_functionality.patch
@Bryan This patch extends the existing org.apache.thrift.test.TestServer to demonstrate the usage of server event handler functionality added in previously posted 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: 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "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
[jira] [Resolved] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Roger Meier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roger Meier resolved THRIFT-1195.
---------------------------------
Resolution: Fixed
patch did not apply on TNonblockingServer.java,
I've put that part on AbstractNonblockingServer.java
committed.
Thanks!
> 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
[jira] [Commented] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058778#comment-13058778 ]
Bryan Duxbury commented on THRIFT-1195:
---------------------------------------
Hey Dragan, would it be possible for you to include some simple tests for this functionality?
> 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
[jira] [Commented] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285400#comment-13285400 ]
Bryan Duxbury commented on THRIFT-1195:
---------------------------------------
I haven't kept up with the state of this ticket, to be honest. I'll try to review what we have here and see if it's committable.
> 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: 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
[jira] [Commented] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "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
[jira] [Issue Comment Edited] (THRIFT-1195) Allow users to act on
client connects/disconnects
Posted by "Dragan Okiljevic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061343#comment-13061343 ]
Dragan Okiljevic edited comment on THRIFT-1195 at 7/7/11 2:30 PM:
------------------------------------------------------------------
@Bryan I just uploaded a patch (Java_Thrift_TestServer_patch_to_demonstrate_ServerEventHandler_functionality.patch) which extends the existing org.apache.thrift.test.TestServer to demonstrate the usage of server event handler functionality added in previously posted patch.
was (Author: dragan.okiljevic):
@Bryan This patch extends the existing org.apache.thrift.test.TestServer to demonstrate the usage of server event handler functionality added in previously posted 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: 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046275#comment-13046275 ]
David Reiss commented on THRIFT-1195:
-------------------------------------
In C++, the TServerEventHandler and TProcessorEventHandler are the hook points for this. It's a little more overhead to have separate objects, but it saves you from having to inject arbitrary special names into the handlers or worrying about default implementations.
> 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
[jira] [Commented] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046271#comment-13046271 ]
Bryan Duxbury commented on THRIFT-1195:
---------------------------------------
What if we changed the compiler to generate special "connect" and "hang up" methods on the interface for the handlers? I think that would be a lot more straightforward and usable, plus it would also set the stage for supporting the feature in other server types.
> 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
[jira] [Commented] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Diwaker Gupta (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (THRIFT-1195) Allow users to act on client
connects/disconnects
Posted by "Dragan Okiljevic (JIRA)" <ji...@apache.org>.
[ 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