[
https://issues.apache.org/jira/browse/GIRAPH-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490299#comment-13490299
]
Eli Reisman commented on GIRAPH-389:
------------------------------------
That makes sense, I was not able to use the "instantiate our own ZK" option
last summer, I was always using the cluster quorum. I wonder if the
single-instance scales well enough to make it the default, a lot of the stuff I
was troubleshooting around ZK back then had a lot to do with slowdowns during
frequent writes & quorum sync's that you guys never have to worry about. After
all, we don't have to have a ZK that is 24-7 available, just per-job. May I ask
whats the most worker tasks you've run on a single ZK this way?
> Multithreading should intelligently allocate the thread pools
> -------------------------------------------------------------
>
> Key: GIRAPH-389
> URL: https://issues.apache.org/jira/browse/GIRAPH-389
> Project: Giraph
> Issue Type: Bug
> Reporter: Avery Ching
> Assignee: Avery Ching
> Fix For: 0.2.0
>
> Attachments: GIRAPH-389.patch
>
>
> Even if the user suggests a very high number of threads, the input split
> threads should not exceed the number splits divided by the number of workers.
> The number of compute threads should not be greater than the number of
> partitions on that worker.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
