You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2008/05/16 01:40:55 UTC
[jira] Created: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
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
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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610081#action_12610081 ]
Bryan Duxbury commented on THRIFT-5:
------------------------------------
Commit message:
{noformat}
THRIFT-5 Need a thread pool server that is fair in terms of invocations, not sockets
This patch adds TNonblockingServer, which supports single-threaded serving, as well as THsHaServer, which performs IO in one thread and method invocations in a configurable thread pool. Also, to support these servers, TNonblockingServerSocket and TNonblockingSocket have been added.
{noformat}
> 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
> Assignee: Bryan Duxbury
> Attachments: thrift-5-v2.patch, thrift-5-v3.patch, thrift-5-v4.patch, thrift-5-v6.patch, thrift-5-v7.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.
[jira] Updated: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-5:
-------------------------------
Patch Info: [Patch Available]
> 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.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.
[jira] Updated: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-5:
-------------------------------
Attachment: thrift-5-v7.patch
This version is all stylistic changes - added _ to the end of instance variables. It also makes the Options in THsHaServer final.
> 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-v6.patch, thrift-5-v7.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.
[jira] Assigned: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury reassigned THRIFT-5:
----------------------------------
Assignee: Bryan Duxbury
> 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
> Assignee: Bryan Duxbury
> Attachments: thrift-5-v2.patch, thrift-5-v3.patch, thrift-5-v4.patch, thrift-5-v6.patch, thrift-5-v7.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.
[jira] Updated: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-5:
-------------------------------
Attachment: thrift-5-v2.patch
Here's a much cleaner version of the server, including the implementation of THsHaServer. I fixed at least one race condition, simplified the code in some places, and added a ton of comments and Javadoc.
In running the TestNonblockingServer and TestClient, I noticed that if you ran the TestClient twice too close together, you'd get exceptions. This was because the last testAsync call blocked for 3 seconds, but the TestClient's socket timeout was only 1 second. I added a new -timeout command line switch that supports setting it to 0 for testing nonblocking servers. Similarly, there is a -hsha switch on TestNonblockingServer that causes it to use the THsHaServer instead of the standard TNonblocking server.
I would love some review comments.
> 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.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.
[jira] Updated: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-5:
-------------------------------
Attachment: thrift-5-v4.patch
This latest version cleans up a lot of stuff, removing unnecessary complexity in the select thread and using fewer states in FrameBuffer operation. The goal was to speed it up a little bit, but I don't think it's going to get much faster. (Simple void method with no params does about 5155 requests/sec on localhost.)
> 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.
[jira] Resolved: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury resolved THRIFT-5.
--------------------------------
Resolution: Fixed
Committed by dreiss.
> 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
> Assignee: Bryan Duxbury
> Attachments: thrift-5-v2.patch, thrift-5-v3.patch, thrift-5-v4.patch, thrift-5-v6.patch, thrift-5-v7.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.
[jira] Updated: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-5:
-------------------------------
Attachment: thrift-5-v3.patch
This version of the patch fixes the improper disconnection handling in TNonblockingServer that was causing the select thread to spin and consume 100% cpu after a disconnection.
> 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.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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Nathan Marz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609059#action_12609059 ]
Nathan Marz commented on THRIFT-5:
----------------------------------
I have reviewed this code, and overall it looks good. Here are my comments:
1. Check that it handles asynchronous calls correctly (it appears Todd has already done this)
2. Since the server requires the top level transport to be TFramedTransport, the constructors should reflect this.
3. Logging should be added throughout the code.
> 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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609379#action_12609379 ]
Todd Lipcon commented on THRIFT-5:
----------------------------------
+1 on v7 of this patch. Looks good to me.
> 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
> Assignee: Bryan Duxbury
> Attachments: thrift-5-v2.patch, thrift-5-v3.patch, thrift-5-v4.patch, thrift-5-v6.patch, thrift-5-v7.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.
[jira] Updated: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-5:
-------------------------------
Attachment: thrift-5-v6.patch
v6 of changes incorporates Todd and Nathan's suggestions, plus a few more little optimizations. I also added logging via java.util.Logger in this version.
To address the async method issue, I followed a strategy like the one Todd suggested with Runnables, except instead I just pass the FrameBuffer itself to requestInvoke calls. Then, the FrameBuffer runs the invocation via the invoke() method, allowing it to track its own state much more easily (and without a new object instantiation each time).
Anyone feel like giving this version a glance over so I know I got it all?
> 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-v6.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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ 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 <to...@amiestreet.com>
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 <to...@amiestreet.com>
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 <to...@amiestreet.com>
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 <to...@amiestreet.com>
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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600342#action_12600342 ]
David Reiss commented on THRIFT-5:
----------------------------------
I think it would be fine for an optional component. For example, we use libevent (rather than raw epoll, kqueue, etc.) in the C++ TNonblockingServer. A TNonblockingServer.java that depends on Mina or Grizzly is better than none at all.
> 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
>
> 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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600335#action_12600335 ]
Bryan Duxbury commented on THRIFT-5:
------------------------------------
Would there be objections to using Mina (or another NIO framework like Grizzly) as the basis for a nonblocking server in Java? I know that in general we want to avoid external dependencies in Thrift, but this seems like a scenario where we'd be able to take advantage of existing projects that would really give us a leg up on implementation.
> 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
>
> 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.
[jira] Updated: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-5:
-------------------------------
Attachment: thrift-5.patch
Here's a first pass at a single-threaded nonblocking-io Java server. It works in my limited testing (TestNonblockingServer and TestClient -framed), but I'm sure there are things that need to be improved.
My plan is to make sure I'm confident with the way this server works, and then make a subclass called THsHaServer that handles the invocations in a thread pool. This should be really simple the way I have things laid out at the moment.
There are a lot of stubs in this code, so be prepared to skip some comments if you're reviewing.
> 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.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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606409#action_12606409 ]
Bryan Duxbury commented on THRIFT-5:
------------------------------------
I agree with that.
I'm starting to consider the requirements for this project - are there others who are interested in chiming in about needed features/behavior?
> 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
>
> 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.
[jira] Commented: (THRIFT-5) Need a thread pool server that is fair
in terms of invocations, not sockets
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600376#action_12600376 ]
David Reiss commented on THRIFT-5:
----------------------------------
I think the end product will be more like the C++ TNonblockingServer (which supports both single-threaded and HS/HA) than any of the existing TThreadPoolServers.
> 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
>
> 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.