You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hama.apache.org by "Thomas Jungblut (Updated) (JIRA)" <ji...@apache.org> on 2011/11/06 12:00:51 UTC

[jira] [Updated] (HAMA-461) Extract a Message Service from BSPPeer

     [ https://issues.apache.org/jira/browse/HAMA-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Jungblut updated HAMA-461:
---------------------------------

    Attachment: HAMA-461_v1.patch

Lots of refactorings. I'm still not sure if this is the final design.
But it is a way to go for our current RPC implementation.

I thought of extending this and offer a asynchronous messaging, but I'll do this on github.

I also revised the synchronization, only the queue for the next iteration which is used by the RPC server is synchronized now. So this should be a slightly bit faster now.

BSPPeer is now not a RPC server anymore.
I'm not sure how we can implement other protocols on top of it, but if we have the need, we can change this.

{noformat}

[INFO] Apache Hama parent POM ............................ SUCCESS [1.652s]
[INFO] Apache Hama Core .................................. SUCCESS [57.303s]
[INFO] Apache Hama Graph Package ......................... SUCCESS [0.771s]
[INFO] Apache Hama Examples .............................. SUCCESS [11.148s]

{noformat}

I hope the peer is now less complex.
                
> Extract a Message Service from BSPPeer
> --------------------------------------
>
>                 Key: HAMA-461
>                 URL: https://issues.apache.org/jira/browse/HAMA-461
>             Project: Hama
>          Issue Type: Improvement
>    Affects Versions: 0.3.0
>            Reporter: Thomas Jungblut
>            Assignee: Thomas Jungblut
>             Fix For: 0.4.0
>
>         Attachments: HAMA-461_v1.patch
>
>
> There's a problem, that we have more synchronized Collections than we need. localQueueForNextIteration (or similar name) is the only one which needs to be thread safe. At least only the put method could be synchronized, because reads does not need to be threadsafe.
> So we should refactor our messaging system from the peer itself. 
> A hint in architecture could give us HAMA-457.
> We have to add a factory which let's the user choice their protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira