[
https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609289#action_12609289
]
Bryan Duxbury commented on THRIFT-5:
------------------------------------
The build.xml thing pointing at some random jar directory sort of bothers me.
It assumes that everyone manages jars the same. I think that we should either
have a project-specific lib directory (say lib/java/lib) which contains the
dependency jars, or just assume the jars are in the global CLASSPATH and fail
when it's not. Personally, I favor the first one, especially because the test
build is actually reliant on an external dependency which is almost definitely
missing by default. It should be easy to run the unit tests - I shouldn't have
to open the build file in order to run tests.
> 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.
