giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Suresh (Commented) (JIRA)" <>
Subject [jira] [Commented] (GIRAPH-80) Don't expose the list holding the messages in BasicVertex
Date Tue, 15 Nov 2011 10:29:51 GMT


Arun Suresh commented on GIRAPH-80:

While the getMessageIterator() method seems like a good idea, I was wondering why we would
need and addMessages(Iterable<M> messages) method. What would that method signify ?
Does it allow the Vertex to add More messages to the list of messages it already received
at the beginning of that superstep ? Does it mean the added messages are available to the
compute function in the current superstep or next superstep ? In which case we already have
the sendMsg(I id, M msg) function. 
> Don't expose the list holding the messages in BasicVertex
> ---------------------------------------------------------
>                 Key: GIRAPH-80
>                 URL:
>             Project: Giraph
>          Issue Type: Improvement
>    Affects Versions: 0.70.0
>            Reporter: Sebastian Schelter
> I'm currently trying to implement my own memory efficient vertex (similar to LongDoubleFloatDoubleVertex)
and ran into problems with getMsgList()
> This method returns a list pointing to the messages of the vertex and it is modified
externally (BasicRPCCommunications calls clear() and addAll() e.g.). This makes it very hard
to use something else than a java.util.List internally (LongDoubleFloatDoubleVertex "hacked"
around this) and it is generally dangerous to have the internal state of an object be modified
externally. It also makes the code harder to read and understand.
> I'd suggest to change the API to let a vertex handle the modifications itself internally
(e.g. add something like pushMessages(...))

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message