Mailing-List: contact hama-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hama-dev@incubator.apache.org
Date: Fri, 21 Oct 2011 12:00:34 +0000 (UTC)
From: "Thomas Jungblut (Commented) (JIRA)" <jira@apache.org>
To: hama-dev@incubator.apache.org
Message-ID: 
 <1896100262.655.1319198434649.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1496777383.539.1319175993678.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HAMA-461) Extract a Message Service from
 BSPPeer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HAMA-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132612#comment-13132612 ] 

Thomas Jungblut commented on HAMA-461:
--------------------------------------

This could have multiple problems.

Hadoop's Writable interface is hacked in all of our classes.
So it would be quite hard for other protocols to deal with this. 

Of course you can always open a ByteArrayOutputStream and set it as the DataOutput and get the real byte codes. But this sucks in performance.
Sadly there is no other way, but refactoring the messages.
I won't do that, because I changed it in the last release and it is currently quite useable. But I cannot remember why I used a marker interface "Messagable" and made an abstract class for a BSPMessage.

Instead it should be a MessagableWritable interface, and other services could then make a MessagableOtherFancyStuff interface. I hope you get the gist.

So within this task, I just refactor out the messaging we currently have in our BSPPeerImpl.

The overall design has to be revisted, though. I would suggest the next release.
                
> 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
>             Fix For: 0.4.0
>
>
> 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