[
https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609055#action_12609055
]
Todd Lipcon commented on THRIFT-5:
----------------------------------
I took a look at this today and made a couple changes. Please check out my git
branch on the thrift-rpc.org repository: pri/tlipcon/thrift-5
Here's the log for JIRA reference:
commit 51da39e973f13287ec983a7cc2d7d35b3da45187
Author: Todd Lipcon <[EMAIL PROTECTED]>
Date: Sat Jun 28 19:04:27 2008 -0400
[thrift-5] modify non blocking Java server to properly handle async void
Switched away from relying on outputTransport.flush() to signify the end
of a processor response. Because async voids never call flush(), the
FrameBuffer was getting stuck in the READ_FRAME_COMPLETE state and
blocking any subsequent requests on the same connection.
We now pass a Runnable into invoke() which should be called when the
processor has completely written its response out.
Test plan: tested server in both normal and hsha modes and verified that
TestClient now completes correctly
commit 9d3534dd55e477328ecd470e43bdd60d10f29643
Author: Todd Lipcon <[EMAIL PROTECTED]>
Date: Sat Jun 28 17:59:14 2008 -0400
[thrift-5] change build.xml to point to /usr/share/java/commons-lang.jar
instead of bryanduxbury's home directory
Is this the best practice for system-wide dependencies with ant?
commit da301cf18d6b5cb78c2bc5b4259f9bc5ffb72bfc
Author: Todd Lipcon <[EMAIL PROTECTED]>
Date: Sat Jun 28 17:43:51 2008 -0400
[thrift-5] Get rid of buffersToKeys map in TNonblockingServer - wasn't
actually used anywhere
commit dccf03d68be3a45eb7a7a80aa32c829c68094ef2
Author: Todd Lipcon <[EMAIL PROTECTED]>
Date: Sat Jun 28 17:42:33 2008 -0400
small style changes in thrift-5:
READ_FRAME renamed to READ_FRAME_COMPLETE for clarity
Inverted an if/else for clarity
Typo in comments
Factored the entering of READING_FRAME_SIZE into a function
[I have an ICLA on file, so I hope this is OK without also uploading a tarball
of the patch series]
> Need a thread pool server that is fair in terms of invocations, not sockets
> ---------------------------------------------------------------------------
>
> Key: THRIFT-5
> URL: https://issues.apache.org/jira/browse/THRIFT-5
> Project: Thrift
> Issue Type: New Feature
> Components: Library (Java)
> Reporter: Bryan Duxbury
> Attachments: thrift-5-v2.patch, thrift-5-v3.patch, thrift-5-v4.patch,
> thrift-5.patch
>
>
> The current TThreadPoolServer in the Java libraries is suboptimal. If you
> actually limit the upper bound of threads, and you have long-lived clients,
> and you have more clients than you have max allowed threads, then any clients
> in excess of the max number of threads will never be given a time slice to
> execute.
> Conceptually, it seems like the correct behavior here is for the individual
> method invocations to be the items that end up on the thread pool's execution
> queue, not the individual client sockets (as it is now). This would support
> this and other use cases better.
> Perhaps we should do a Half-Sync/Half-Async server to fulfill this goal?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
