[
https://issues.apache.org/jira/browse/HAMA-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596331#comment-13596331
]
Thomas Jungblut commented on HAMA-742:
--------------------------------------
bq. We can do it either ways with SpillingQueue. I did make an attempt to keep
it a single object within if possible.( There are 2 versions of poll - M poll(M
msg) and M poll()) HAMA-706 patch should look into using it and make it less
dirty there.
I see your "objectWritableMode" there. That is a very good idea.
bq.Currently, by default, we process 16K spilled data at a time.
Just curious, how did you determine this 16k? I would say a much more larger
size would be optimal, MPI uses MP_BUFFER_MEM which is correlated with the
number of launched tasks. The default up to 512 tasks is 64mb, like the default
blocksize of HDFS.
bq. The receiver queue would be reading from the BSPMessageBundle. It would be
a part of the protocol
That is also very nice. Do you have some early stage patch to peek for me?
> Implement of Hama RPC
> ----------------------
>
> Key: HAMA-742
> URL: https://issues.apache.org/jira/browse/HAMA-742
> Project: Hama
> Issue Type: Sub-task
> Reporter: Edward J. Yoon
> Fix For: 0.6.1
>
>
> To solve HDFS 2.0 compatibility issue, we have to change a lot of codes for
> Hadoop 2.0 RPC, moreover, yarn RPC doesn't support asynchronous call directly.
> Ultimately, we can pursue the performance and integrate more easily with
> hadoop multi-versions by having our own RPC.
--
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
