Mailing-List: contact user-help@giraph.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@giraph.apache.org
Received-SPF: pass (athena.apache.org: domain of pmorgan246@gmail.com
 designates 74.125.82.171 as permitted sender)
MIME-Version: 1.0
Date: Sat, 2 Mar 2013 12:31:33 +0000
Message-ID: 
 <CAEfyqh6kGNHNENUW1FQrSk5n7OktQp7zTOb0rNOSKA6vLX1gYw@mail.gmail.com>
Subject: Several Queries
From: Peter Morgan <pmorgan246@gmail.com>
To: user@giraph.apache.org
Content-Type: multipart/alternative; boundary=047d7ba98302dbbf2004d6f04d9c

--047d7ba98302dbbf2004d6f04d9c
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have several questions/comments relating to various parts of Giraph. Not
sure whether they should be here or in the dev mailing list. They might
have already been answered somewhere.

1) When is there likely to be a new release of Giraph, its been a while
since the last one and I know there has been a lot of work on it?

2) I've been using the AccumuloVertexInputFormat, and not found it very
useful - it is most likely that graph data held in Accumulo is an edge
list, so would it not be better that the Accumulo Input Format for Giraph
extends EdgeInputFormat instead? The current example for using with
Accumulo is called AccumuloEdgeInputFormat (which extends
AccumuloVertexInputFormat) - that seems to be badly named? I was also
wondering what the behaviour is when using a VertexInputFormat but with an
edge list - do vertices created later in the input override previous ones,
and so edges get lost/ not added?

3) Is there a way to ensure that if the input file doesn't exist, the
giraph job (and hence MR job) will exit, and not hang?

4) The SequenceFileReader currently assumes that the Key type is going to
be the same as the Vertex name type, but in my case this isn't true. Is
there, or can there be a version which allows the Sequence file key and
value be different to the giraph vertex name, state, edge and message
types.

5) I've been having a problem with a Giraph job successfully finishing, but
the process/jvm on each compute node not being killed properly and it just
sits there idle, but keeping the RAM that the job has used. Doesn't seem to
be a problem when we run normal MR. We then have to manually kill each
process to release the RAM. Any ideas why this might be happening?

Thanks in advance for any help.
Peter

--047d7ba98302dbbf2004d6f04d9c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I have several questions/comments relating to variou=
s parts of Giraph. Not sure whether they should be here or in the dev maili=
ng list. They might have already been answered somewhere.</div><div><br>
</div><div>1) When is there likely to be a new release of Giraph, its been =
a while since the last one and I know there has been a lot of work on it?</=
div><div><br></div><div>2) I&#39;ve been using the AccumuloVertexInputForma=
t, and not found it very useful - it is most likely that graph data held in=
 Accumulo is an edge list, so would it not be better that the Accumulo Inpu=
t Format for Giraph extends EdgeInputFormat instead? The current example fo=
r using with Accumulo is called AccumuloEdgeInputFormat (which extends Accu=
muloVertexInputFormat) - that seems to be badly named? I was also wondering=
 what the behaviour is when using a VertexInputFormat but with an edge list=
 - do vertices created later in the input override previous ones, and so ed=
ges get lost/ not added?</div>
<div><br></div><div>3) Is there a way to ensure that if the input file does=
n&#39;t exist, the giraph job (and hence MR job) will exit, and not hang?</=
div><div><br></div><div>4) The SequenceFileReader currently assumes that th=
e Key type is going to be the same as the Vertex name type, but in my case =
this isn&#39;t true. Is there, or can there be a version which allows the S=
equence file key and value be different to the giraph vertex name, state, e=
dge and message types.=A0</div>
<div><br></div><div>5) I&#39;ve been having a problem with a Giraph job=A0s=
uccessfully finishing, but the process/jvm on each compute node not being k=
illed properly and it just sits there idle, but keeping the RAM that the jo=
b has used. Doesn&#39;t seem to be a problem when we run normal MR. We then=
 have to manually kill each process to release the RAM. Any ideas why this =
might be happening?</div>
<div><br></div><div>Thanks in advance for any help.</div><div>Peter=A0</div=
>

--047d7ba98302dbbf2004d6f04d9c--