Now, that way looks good. Probably, later we could improve that like Context
of MapReduce.

--
Hyunsik Choi
Database Lab, Korea University

On Sat, Oct 1, 2011 at 3:01 AM, Avery Ching <ach...@apache.org> wrote:
> It isn't visible (purposefully) since it is internal state.
>
> That being said, I believe this type of functionality would be useful.
>  Right now there is a lot of ugly static variables stored in Vertex
> implementations because of it.  Perhaps we should add another method in
> GiraphJob
>
> final public void setWorkerObjectClass(Class<? extends Configurable>
> workerObjectClass);
>
> Then in BasicVertex
>
> public void preApplication(Configurable workerObject);
> public void postApplication(Configurable workerObject);
> public void preSuperstep(Configurable workerObject);
> public void postSuperstep(Configurable workerObject);
> public Configurable getWorkerObject();
>
> Anyone else think of a cleaner way to do it?
>
> Avery
>
> On 9/30/11 8:42 AM, Claudio Martella wrote:
>>
>> afaik getGraphState() is not visible to my object. Or?
>>
>> On Fri, Sep 30, 2011 at 5:23 PM, Jake Mannix<jake.man...@gmail.com>
>>  wrote:
>>>
>>> Remember that there's already a "singleton"-like object available to all
>>> vertices: the GraphState object, which has a handle on the GraphMapper.
>>> Maybe this is the right place to get your handle on the
>>> FSDataOutputStream?
>>>   -jake
>>> On Fri, Sep 30, 2011 at 7:25 AM, Claudio Martella
>>> <claudio.marte...@gmail.com>  wrote:
>>>>
>>>> Hello,
>>>>
>>>> to my understanding pre/post Application/Superstep methods are called
>>>> ONCE on a "fake" vertex on each worker (the so called
>>>> representativeVertex). This means that these methods should not depend
>>>> on any specific-vertex data.
>>>>
>>>> As I'm trying to sort out my Emitter, I thought I could create one
>>>> FSDataOutputStream per worker which each Vertex belonging to that
>>>> worker could share (which would be even thread-safe as each worker is
>>>> not parallel).
>>>>
>>>> The questions are:
>>>>
>>>> 1) how to share the FSDataOutputFormat object created at
>>>> preApplication() (and closed at postApplication()) created by this
>>>> representativeVertex?
>>>>
>>>> 2) about the filename, I'd be happy to have access to the Worker Id so
>>>> to create an outputfile filename as with happens with reducers and
>>>> part files by FileOutputFormat (i.e.<userdefinedfilename>-workerid).
>>>>
>>>>
>>>> The "best" idea i have in my mind right now is to use the calling
>>>> vertex (the representativeVertex) hashCode as the id, and create an
>>>> external Singleton where i can request register and request the
>>>> outputfiles similarly to what happens with Aggregators now, and by
>>>> passing the *this* reference as an index to this map. Any better idea?
>>>> :)
>>>>
>>>>
>>>> --
>>>>     Claudio Martella
>>>>     claudio.marte...@gmail.com
>>>
>>
>>
>
>

Reply via email to