PageRank on custom input
Hi, We want to run a PageRank job (similar to PageRankBenchmark) for custom input graph. Is there an example for this? Giraph's website has a page for this but it is incomplete - http://giraph.apache.org/pagerank.html Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University
RE: [Solved] Giraph job hangs indefinitely and is eventually killed by JobTracker
Hi Vikesh, It seems that you are trying to run benchmarks on giraph.We had a lot of improvements in 1.1.0-SNAPSHOT - (though it is not released publicly in maven at Facebook we run all our applications on the snapshot version)So, you can pull the latest trunk from giraph: git clone https://git-wip-us.apache.org/repos/asf/giraph.git And then try running some applications. [you are correct, we store hostnames-taskid mappings in the beginning of the run, so u can see such failures] Date: Mon, 7 Apr 2014 16:27:09 -0700 From: vik...@stanford.edu To: user@giraph.apache.org Subject: [Solved] Giraph job hangs indefinitely and is eventually killed by JobTracker Hi, Thanks for the help! Turns out this was happening because /etc/hosts had an outdated IP address (dynamic) for the host that was being used as the master. Giraph was probably failing to communicate with the master throughout and getting stuck indefinitely. Thanks,Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University From: "Vikesh Khanna" To: user@giraph.apache.org Sent: Monday, April 7, 2014 2:58:13 PM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker @Pankaj, I am running the ShortestPath example on a tiny graph now (5 nodes). That is also getting hung indefinitely the exact same way. This machine has 1 TB of memory and I have used -Xmx25g (25 GB) as Java options. So hopefully it should not be because of memory limitation. [(free/total/max) = 1706.68M / 1979.75M / 25242.25M] @Lukas, I am trying to run the example packaged with the Giraph installation - SimpleShortestPathsVertex. I haven't written any code myself yet - just trying to get this to work first. I am not getting any memory exception - no dump file is being generated at the DumpPath. $HADOOP_HOME/bin/hadoop jar ~/.local/bin/giraph-examples.jar org.apache.giraph.GiraphRunner -D giraph.logLevel="all" -libjars ~/.local/bin/giraph-core.jar org.apache.giraph.examples.SimpleShortestPathsVertex -vif org.apache.giraph.io.formats.JsonLongDoubleFloatDoubleVertexInputFormat -vip /user/vikesh/input/tiny_graph.txt -of org.apache.giraph.io.formats.IdWithValueTextOutputFormat -op /user/vikesh/shortestPaths8 -ca SimpleShortestPathsVertex.source=2 -w 1 I am printing debug level logs now, and I am seeing these calls indefinitely in both the zookeeper and worker tasks - 2014-04-07 14:45:32,325 DEBUG org.apache.hadoop.ipc.RPC: Call: statusUpdate 8 2014-04-07 14:45:35,326 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 sending #34 2014-04-07 14:45:35,327 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 got value #34 2014-04-07 14:45:35,327 DEBUG org.apache.hadoop.ipc.RPC: Call: ping 2 2014-04-07 14:45:38,328 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 sending #35 2014-04-07 14:45:38,329 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 got value #35 2014-04-07 14:45:38,329 DEBUG org.apache.hadoop.ipc.RPC: Call: ping 1 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Got timed signaled of false 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Wait for 0 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Got timed signaled of false 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Wait for 0These calls go on for 10 minutes and then the job is killed by Hadoop. Thanks,Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University From: "Lukas Nalezenec" To: user@giraph.apache.org Sent: Monday, April 7, 2014 4:13:23 AM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker Hi, Try making and analyzing memory dump after exception (JVM param -XX:+HeapDumpOnOutOfMemoryError) What configuration (mainly Partition class) do you use ? Lukas On 7.4.2014 11:45, Vikesh Khanna wrote: Hi, Any ideas why Giraph waits indefinitely? I've been stuck on this for a long time now. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University From: "Vikesh Khanna" To: user@giraph.apache.org Sent: Friday, April 4, 2014 6:06:51 AM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker Hi Avery, I tried both the options. It does appear to be a GC problem. The problem continues with the second
[Solved] Giraph job hangs indefinitely and is eventually killed by JobTracker
Hi, Thanks for the help! Turns out this was happening because /etc/hosts had an outdated IP address (dynamic) for the host that was being used as the master. Giraph was probably failing to communicate with the master throughout and getting stuck indefinitely. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Vikesh Khanna" To: user@giraph.apache.org Sent: Monday, April 7, 2014 2:58:13 PM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker @Pankaj, I am running the ShortestPath example on a tiny graph now (5 nodes). That is also getting hung indefinitely the exact same way. This machine has 1 TB of memory and I have used -Xmx25g (25 GB) as Java options. So hopefully it should not be because of memory limitation. [ (free/total/max) = 1706.68M / 1979.75M / 25242.25M ] @Lukas, I am trying to run the example packaged with the Giraph installation - SimpleShortestPathsVertex. I haven't written any code myself yet - just trying to get this to work first. I am not getting any memory exception - no dump file is being generated at the DumpPath. $HADOOP_HOME/bin/hadoop jar ~/.local/bin/giraph-examples.jar org.apache.giraph.GiraphRunner -D giraph.logLevel="all" -libjars ~/.local/bin/giraph-core.jar org.apache.giraph.examples.SimpleShortestPathsVertex -vif org.apache.giraph.io.formats.JsonLongDoubleFloatDoubleVertexInputFormat -vip /user/vikesh/input/tiny_graph.txt -of org.apache.giraph.io.formats.IdWithValueTextOutputFormat -op /user/vikesh/shortestPaths8 -ca SimpleShortestPathsVertex.source=2 -w 1 I am printing debug level logs now, and I am seeing these calls indefinitely in both the zookeeper and worker tasks - 2014-04-07 14:45:32,325 DEBUG org.apache.hadoop.ipc.RPC: Call: statusUpdate 8 2014-04-07 14:45:35,326 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 sending #34 2014-04-07 14:45:35,327 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 got value #34 2014-04-07 14:45:35,327 DEBUG org.apache.hadoop.ipc.RPC: Call: ping 2 2014-04-07 14:45:38,328 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 sending #35 2014-04-07 14:45:38,329 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 got value #35 2014-04-07 14:45:38,329 DEBUG org.apache.hadoop.ipc.RPC: Call: ping 1 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Got timed signaled of false 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Wait for 0 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Got timed signaled of false 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Wait for 0 These calls go on for 10 minutes and then the job is killed by Hadoop. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Lukas Nalezenec" To: user@giraph.apache.org Sent: Monday, April 7, 2014 4:13:23 AM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker Hi, Try making and analyzing memory dump after exception (JVM param -XX:+HeapDumpOnOutOfMemoryError ) What configuration (mainly Partition class) do you use ? Lukas On 7.4.2014 11:45, Vikesh Khanna wrote: Hi, Any ideas why Giraph waits indefinitely? I've been stuck on this for a long time now. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Vikesh Khanna" To: user@giraph.apache.org Sent: Friday, April 4, 2014 6:06:51 AM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker Hi Avery, I tried both the options. It does appear to be a GC problem. The problem continues with the second option as well :(. I have attached the logs after enabling the first set of options and using 1 worker. Would be very helpful if you can take a look. This machine has 1 TB memory. We ran benchmarks of various other graph libraries on this machine and they worked fine (even with graphs 10x larger than the Giraph PageRank benchmark - 40 million nodes). I am sure Giraph would work fine as well - this should not be a resource constraint. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Avery Ching" To: user@giraph.apache.org Sent: Thursday, April 3, 2014 7:26:56 PM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker This is for a single worker it appears. Most likely your worker went into GC and never returned. You can try with GC settings turned on, try adding something like. -XX:+PrintGC -XX:+P
Re: zookeeper problem in giraph..
Hi, Lukas,
Got the patch applied to
giraph-core/src/main/java/org/apache/giraph/comm/netty/NettyClient.java and
recompiled giraph by "mvn compile", but still the same error:
14/04/07 16:51:26 INFO job.JobProgressTracker: Data from 8 workers -
Compute superstep 2: 0 out of 4847571 vertices computed; 0 out of 64
partitions computed; min free memory on worker 5 - 270.76MB, average
394.74MB
14/04/07 16:51:27 INFO zookeeper.ClientCnxn: Unable to read additional data
from server sessionid 0x1453e2b3cca0009, likely server has closed socket,
closing socket connection and attempting reconnect
14/04/07 16:51:29 INFO zookeeper.ClientCnxn: Opening socket connection to
server compute-0-19.local/10.1.255.235:22181. Will not attempt to
authenticate using SASL (unknown error)
14/04/07 16:51:29 WARN zookeeper.ClientCnxn: Session 0x1453e2b3cca0009 for
server null, unexpected error, closing socket connection and attempting
reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739)
at
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1068)
14/04/07 16:51:31 INFO zookeeper.ClientCnxn: Opening socket connection to
server compute-0-19.local/10.1.255.235:22181. Will not attempt to
authenticate using SASL (unknown error)
I tried to modify some parameters in:
./giraph-core/src/main/java/org/apache/giraph/conf/GiraphConstants.java
like DEFAULT_ZOOKEEPER_MAX_CLIENT_CNXNS
but seems have no effect. Any hints?
Best Regards,
Suijian
2014-04-07 9:34 GMT-05:00 Suijian Zhou :
> Hi, Lukas,
> Thank you, but when I tried to apply the patch, I got:
> 2014.04.07|09:25:47~/giraph/giraph-core/src> git apply --check
> NettyClient_Timeout.patch
> error: patch failed:
> giraph-core/src/main/java/org/apache/giraph/comm/netty/NettyClient.java:153
> error:
> giraph-core/src/main/java/org/apache/giraph/comm/netty/NettyClient.java:
> patch does not apply
>
> Could you send me directly the new patched NettyClient.java file? Thanks!
>
> Best Regards,
> Suijian
>
>
>
> 2014-04-04 17:12 GMT-05:00 Lukas Nalezenec <
> lukas.naleze...@firma.seznam.cz>:
>
> Hi,
>>
>> I had similar issue, it was caused by long GC pauses. I patched
>> NettyClient so when reconnect fails it sleeps for some time before next
>> try. Patch is enclosed. Let me know if it works for you.
>> I would try tuning GC. You can also try to use
>> giraph.waitForRequestsConfirmation and giraph.maxNumberOfOpenRequests .
>> I hope I am right.
>>
>> Regards
>> Lukas
>>
>>
>> On 4.4.2014 22:49, Suijian Zhou wrote:
>>
>> Hi,
>> I have a zookeeper problem when running a giraph program, the program
>> will be aborted in superstep 2 as:
>> 14/04/04 15:44:48 INFO zookeeper.ClientCnxn: Opening socket connection to
>> server compute-0-18.local/10.1.255.236:22181. Will not attempt to
>> authenticate using SASL (unknown error)
>> 14/04/04 15:44:48 INFO zookeeper.ClientCnxn: Socket connection
>> established to compute-0-18.local/10.1.255.236:22181, initiating session
>> 14/04/04 15:44:48 INFO zookeeper.ClientCnxn: Session establishment
>> complete on server compute-0-18.local/10.1.255.236:22181, sessionid =
>> 0x1452e7c79910009, negotiated timeout = 60
>> ..
>> 14/04/04 15:46:08 INFO job.JobProgressTracker: Data from 8 workers -
>> Compute superstep 2: 0 out of 4847571 vertices computed; 0 out of 64
>> partitions computed; min free memory on worker 3 - 270.37MB, average
>> 451.21MB
>> 14/04/04 15:46:13 INFO job.JobProgressTracker: Data from 8 workers -
>> Compute superstep 2: 0 out of 4847571 vertices computed; 0 out of 64
>> partitions computed; min free memory on worker 6 - 249.25MB, average
>> 404.02MB
>> 14/04/04 15:46:16 INFO zookeeper.ClientCnxn: Unable to read additional
>> data from server sessionid 0x1452e7c79910009, likely server has closed
>> socket, closing socket connection and attempting reconnect
>> 14/04/04 15:46:17 INFO zookeeper.ClientCnxn: Opening socket connection to
>> server compute-0-18.local/10.1.255.236:22181. Will not attempt to
>> authenticate using SASL (unknown error)
>> 14/04/04 15:46:17 WARN zookeeper.ClientCnxn: Session 0x1452e7c79910009
>> for server null, unexpected error, closing socket connection and attempting
>> reconnect
>> java.net.ConnectException: Connection refused
>>
>>
>> Each rerun of the program will lead to another computing node reporting
>> the same error("Unable to read additional data from server sessionid...").
>>
>> What in superstep 2 are:
>> if (getSuperstep() == 2) {
>> for (IntWritable message: messages) {
>> for (Edge edge: vertex.getEdges()) {
>>sendMessage(edge.getTargetVertexId(), message);
>>//int abc=0;
>> }
>> }
>> }
>>
>> Checked that if I replace the line
>> "sendMessage(edge.getTargetVertexId(), message);" to anot
Re: Giraph job hangs indefinitely and is eventually killed by JobTracker
@Pankaj, I am running the ShortestPath example on a tiny graph now (5 nodes). That is also getting hung indefinitely the exact same way. This machine has 1 TB of memory and I have used -Xmx25g (25 GB) as Java options. So hopefully it should not be because of memory limitation. [ (free/total/max) = 1706.68M / 1979.75M / 25242.25M ] @Lukas, I am trying to run the example packaged with the Giraph installation - SimpleShortestPathsVertex. I haven't written any code myself yet - just trying to get this to work first. I am not getting any memory exception - no dump file is being generated at the DumpPath. $HADOOP_HOME/bin/hadoop jar ~/.local/bin/giraph-examples.jar org.apache.giraph.GiraphRunner -D giraph.logLevel="all" -libjars ~/.local/bin/giraph-core.jar org.apache.giraph.examples.SimpleShortestPathsVertex -vif org.apache.giraph.io.formats.JsonLongDoubleFloatDoubleVertexInputFormat -vip /user/vikesh/input/tiny_graph.txt -of org.apache.giraph.io.formats.IdWithValueTextOutputFormat -op /user/vikesh/shortestPaths8 -ca SimpleShortestPathsVertex.source=2 -w 1 I am printing debug level logs now, and I am seeing these calls indefinitely in both the zookeeper and worker tasks - 2014-04-07 14:45:32,325 DEBUG org.apache.hadoop.ipc.RPC: Call: statusUpdate 8 2014-04-07 14:45:35,326 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 sending #34 2014-04-07 14:45:35,327 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 got value #34 2014-04-07 14:45:35,327 DEBUG org.apache.hadoop.ipc.RPC: Call: ping 2 2014-04-07 14:45:38,328 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 sending #35 2014-04-07 14:45:38,329 DEBUG org.apache.hadoop.ipc.Client: IPC Client (47) connection to /127.0.0.1:45894 from job_201404071443_0001 got value #35 2014-04-07 14:45:38,329 DEBUG org.apache.hadoop.ipc.RPC: Call: ping 1 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Got timed signaled of false 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Wait for 0 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Got timed signaled of false 2014-04-07 14:45:38,910 DEBUG org.apache.giraph.zk.PredicateLock: waitMsecs: Wait for 0 These calls go on for 10 minutes and then the job is killed by Hadoop. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Lukas Nalezenec" To: user@giraph.apache.org Sent: Monday, April 7, 2014 4:13:23 AM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker Hi, Try making and analyzing memory dump after exception (JVM param -XX:+HeapDumpOnOutOfMemoryError ) What configuration (mainly Partition class) do you use ? Lukas On 7.4.2014 11:45, Vikesh Khanna wrote: Hi, Any ideas why Giraph waits indefinitely? I've been stuck on this for a long time now. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Vikesh Khanna" To: user@giraph.apache.org Sent: Friday, April 4, 2014 6:06:51 AM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker Hi Avery, I tried both the options. It does appear to be a GC problem. The problem continues with the second option as well :(. I have attached the logs after enabling the first set of options and using 1 worker. Would be very helpful if you can take a look. This machine has 1 TB memory. We ran benchmarks of various other graph libraries on this machine and they worked fine (even with graphs 10x larger than the Giraph PageRank benchmark - 40 million nodes). I am sure Giraph would work fine as well - this should not be a resource constraint. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Avery Ching" To: user@giraph.apache.org Sent: Thursday, April 3, 2014 7:26:56 PM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker This is for a single worker it appears. Most likely your worker went into GC and never returned. You can try with GC settings turned on, try adding something like. -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc You could also try the concurrent mark/sweep collector. -XX:+UseConcMarkSweepGC Any chance you can use more workers and/or get more memory? Avery On 4/3/14, 5:46 PM, Vikesh Khanna wrote: @Avery, Thanks for the help. I checked out the task logs, and turns out there was an exception "GC overhead limit exceeded" due to which the benchmarks wouldn't even load the vertices. I got around it by increasing the heap size (mapred.child.java.opts) in mapred-site.xml. The benchmar
RE: voteToHalt vs removeVertexRequest
Thank you Avery, actually I am only interested in a reduced set of vertexes for the output. Regards, Liannet -Original Message- From: "Avery Ching" Sent: 07/04/2014 18:56 To: "user@giraph.apache.org" Subject: Re: voteToHalt vs removeVertexRequest Pretty much. But when you remove the vertex, you won't be able to dump its output (not that all applications need to). Avery On 4/7/14, 9:38 AM, Liannet Reyes wrote: > Hi, > > Because of my algorithm I am able to detect when a vertex won't be > used anymore, what would be more accurate : voteToHalt or removeVertex. > > I imagine that removing the vertexes I can free some memory and > although it have some cost in execution time that is not a big deal as > the graph is smaller each time. Am I right? > > Regards, > > Liannet > >
Re: voteToHalt vs removeVertexRequest
Pretty much. But when you remove the vertex, you won't be able to dump its output (not that all applications need to). Avery On 4/7/14, 9:38 AM, Liannet Reyes wrote: Hi, Because of my algorithm I am able to detect when a vertex won't be used anymore, what would be more accurate : voteToHalt or removeVertex. I imagine that removing the vertexes I can free some memory and although it have some cost in execution time that is not a big deal as the graph is smaller each time. Am I right? Regards, Liannet
voteToHalt vs removeVertexRequest
Hi, Because of my algorithm I am able to detect when a vertex won't be used anymore, what would be more accurate : voteToHalt or removeVertex. I imagine that removing the vertexes I can free some memory and although it have some cost in execution time that is not a big deal as the graph is smaller each time. Am I right? Regards, Liannet
RE: Can a vertex belong to more than one partition
If you want the vertex.value to be available to all vertices, then you can store it in an aggregator.A vertex can belong to exactly one partition. But please answer Lukas's questions so we can answer more appropriately. > Date: Mon, 7 Apr 2014 11:23:58 +0200 > From: lukas.naleze...@firma.seznam.cz > To: user@giraph.apache.org > Subject: Re: Can a vertex belong to more than one partition > > Hi, > > No, Vertex can belong only to one partition. > Can you describe algorithm you are solving ? How many those vertexes > belonging to all partitions you have ? > Why do you need so strict partitioning ? > > Regards > Lukas > > > On 6.4.2014 12:38, Akshay Trivedi wrote: > > In order to custom partition the graph, WorkerGraphPartitioner has to > > be implemented. It has a method getPartitionOwner(I vertexId) which > > returns PartitionOwner of the vertex. I want that some vertices belong > > to all paritions i.e all PartitionOwners. Can anyone help me with it? > > Thankyou in advance > > > > Regards > > Akshay >
Re: zookeeper problem in giraph..
Hi, Lukas,
Thank you, but when I tried to apply the patch, I got:
2014.04.07|09:25:47~/giraph/giraph-core/src> git apply --check
NettyClient_Timeout.patch
error: patch failed:
giraph-core/src/main/java/org/apache/giraph/comm/netty/NettyClient.java:153
error:
giraph-core/src/main/java/org/apache/giraph/comm/netty/NettyClient.java:
patch does not apply
Could you send me directly the new patched NettyClient.java file? Thanks!
Best Regards,
Suijian
2014-04-04 17:12 GMT-05:00 Lukas Nalezenec
:
> Hi,
>
> I had similar issue, it was caused by long GC pauses. I patched
> NettyClient so when reconnect fails it sleeps for some time before next
> try. Patch is enclosed. Let me know if it works for you.
> I would try tuning GC. You can also try to use
> giraph.waitForRequestsConfirmation and giraph.maxNumberOfOpenRequests .
> I hope I am right.
>
> Regards
> Lukas
>
>
> On 4.4.2014 22:49, Suijian Zhou wrote:
>
> Hi,
> I have a zookeeper problem when running a giraph program, the program
> will be aborted in superstep 2 as:
> 14/04/04 15:44:48 INFO zookeeper.ClientCnxn: Opening socket connection to
> server compute-0-18.local/10.1.255.236:22181. Will not attempt to
> authenticate using SASL (unknown error)
> 14/04/04 15:44:48 INFO zookeeper.ClientCnxn: Socket connection established
> to compute-0-18.local/10.1.255.236:22181, initiating session
> 14/04/04 15:44:48 INFO zookeeper.ClientCnxn: Session establishment
> complete on server compute-0-18.local/10.1.255.236:22181, sessionid =
> 0x1452e7c79910009, negotiated timeout = 60
> ..
> 14/04/04 15:46:08 INFO job.JobProgressTracker: Data from 8 workers -
> Compute superstep 2: 0 out of 4847571 vertices computed; 0 out of 64
> partitions computed; min free memory on worker 3 - 270.37MB, average
> 451.21MB
> 14/04/04 15:46:13 INFO job.JobProgressTracker: Data from 8 workers -
> Compute superstep 2: 0 out of 4847571 vertices computed; 0 out of 64
> partitions computed; min free memory on worker 6 - 249.25MB, average
> 404.02MB
> 14/04/04 15:46:16 INFO zookeeper.ClientCnxn: Unable to read additional
> data from server sessionid 0x1452e7c79910009, likely server has closed
> socket, closing socket connection and attempting reconnect
> 14/04/04 15:46:17 INFO zookeeper.ClientCnxn: Opening socket connection to
> server compute-0-18.local/10.1.255.236:22181. Will not attempt to
> authenticate using SASL (unknown error)
> 14/04/04 15:46:17 WARN zookeeper.ClientCnxn: Session 0x1452e7c79910009 for
> server null, unexpected error, closing socket connection and attempting
> reconnect
> java.net.ConnectException: Connection refused
>
>
> Each rerun of the program will lead to another computing node reporting
> the same error("Unable to read additional data from server sessionid...").
>
> What in superstep 2 are:
> if (getSuperstep() == 2) {
> for (IntWritable message: messages) {
> for (Edge edge: vertex.getEdges()) {
>sendMessage(edge.getTargetVertexId(), message);
>//int abc=0;
> }
> }
> }
>
> Checked that if I replace the line "sendMessage(edge.getTargetVertexId(),
> message);" to another meaningless line like "int abc=0;", the program could
> be finished successfully. Seems a ZooKeeper problem but this seems comes
> with giraph as I did not install ZooKeeper seperately. I tried to modify
> parameters in GiraphConstants.java and re-compile giraph, but it seems do
> not take any effects as I see in the screen output the parameters were not
> changed at all. Any hints?
>
>Best Regards,
>Suijian
>
>
>
Re: Giraph job hangs indefinitely and is eventually killed by JobTracker
Hi, |Try making and analyzing memory dump after exception (JVM param -XX:+HeapDumpOnOutOfMemoryError|) What configuration (mainly Partition class) do you use ? Lukas On 7.4.2014 11:45, Vikesh Khanna wrote: Hi, Any ideas why Giraph waits indefinitely? I've been stuck on this for a long time now. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University *From: *"Vikesh Khanna" *To: *user@giraph.apache.org *Sent: *Friday, April 4, 2014 6:06:51 AM *Subject: *Re: Giraph job hangs indefinitely and is eventually killed by JobTracker Hi Avery, I tried both the options. It does appear to be a GC problem. The problem continues with the second option as well :(. I have attached the logs after enabling the first set of options and using 1 worker. Would be very helpful if you can take a look. This machine has 1 TB memory. We ran benchmarks of various other graph libraries on this machine and they worked fine (even with graphs 10x larger than the Giraph PageRank benchmark - 40 million nodes). I am sure Giraph would work fine as well - this should not be a resource constraint. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University *From: *"Avery Ching" *To: *user@giraph.apache.org *Sent: *Thursday, April 3, 2014 7:26:56 PM *Subject: *Re: Giraph job hangs indefinitely and is eventually killed by JobTracker This is for a single worker it appears. Most likely your worker went into GC and never returned. You can try with GC settings turned on, try adding something like. -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc You could also try the concurrent mark/sweep collector. -XX:+UseConcMarkSweepGC Any chance you can use more workers and/or get more memory? Avery On 4/3/14, 5:46 PM, Vikesh Khanna wrote: @Avery, Thanks for the help. I checked out the task logs, and turns out there was an exception "GC overhead limit exceeded" due to which the benchmarks wouldn't even load the vertices. I got around it by increasing the heap size (mapred.child.java.opts) in mapred-site.xml. The benchmark is loading vertices now. However, the job is still getting stuck indefinitely (and eventually killed). I have attached the small log for the map task on 1 worker. Would really appreciate if you can help understand the cause. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University *From: *"Praveen kumar s.k" *To: *user@giraph.apache.org *Sent: *Thursday, April 3, 2014 4:40:07 PM *Subject: *Re: Giraph job hangs indefinitely and is eventually killed by JobTracker You have given -w 30, make sure that that many number of map tasks are configured in your cluster On Thu, Apr 3, 2014 at 6:24 PM, Avery Ching wrote: > My guess is that you don't get your resources. It would be very helpful to > print the master log. You can find it when the job is running to look at > the Hadoop counters on the job UI page. > > Avery > > > On 4/3/14, 12:49 PM, Vikesh Khanna wrote: > > Hi, > > I am running the PageRank benchmark under giraph-examples from giraph-1.0.0 > release. I am using the following command to run the job (as mentioned here) > > vikesh@madmax > /lfs/madmax/0/vikesh/usr/local/giraph/giraph-examples/src/main/java/org/apache/giraph/examples > $ $HADOOP_HOME/bin/hadoop jar > $GIRAPH_HOME/giraph-core/target/giraph-1.0.0-for-hadoop-0.20.203.0-jar-with-dependencies.jar > org.apache.giraph.benchmark.PageRankBenchmark -e 1 -s 3 -v -V 5000 -w 30 > > > However, the job gets stuck at map 9% and is eventually killed by the > JobTracker on reaching the mapred.task.timeout (default 10 minutes). I tried > increasing the timeout to a very large value, and the job went on for over 8 > hours without completion. I also tried the ShortestPathsBenchmark, which > also fails the same way. > > > Any help is appreciated. > > > ** *** > > > Machine details: > > Linux version 2.6.32-279.14.1.el6.x86_64 > (mockbu...@c6b8.bsys.dev.centos.org) (gcc version 4.4.6 20120305 (Red Hat > 4.4.6-4) (GCC) ) #1 SMP Tue Nov 6 23:43:09 UTC 2012 > > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > CPU(s): 64 > On-line CPU(s) list: 0-63 > Thread(s) per core: 1 > Core(s) per socket: 8 > CPU socket(s): 8 > NUMA node(s): 8 > Vendor ID: GenuineIntel > CPU family: 6 > Model: 47 > Stepping: 2
Re: Giraph job hangs indefinitely and is eventually killed by JobTracker
In task1.txt 2014-04-04 00:48:43,575 INFO org.apache.giraph.worker.VertexInputSplitsCallable: readVertexInputSplit: Loaded 4800 vertices at 150388.2505243918 vertices/sec 4800 edges at 150389.47626503918 edges/sec Memory (free/total/max) = 1143.96M / 9102.25M / 9102.25M IMHO the worker has used almost all the memory available and not much memory is left for the process to continue. Also you may try the "top" or "free" command to see what is the memory usage. Regards, Pankaj On 7 April 2014 15:15, Vikesh Khanna wrote: > Hi, > > Any ideas why Giraph waits indefinitely? I've been stuck on this for a > long time now. > > Thanks, > Vikesh Khanna, > Masters, Computer Science (Class of 2015) > Stanford University > > > -- > *From: *"Vikesh Khanna" > *To: *user@giraph.apache.org > *Sent: *Friday, April 4, 2014 6:06:51 AM > > *Subject: *Re: Giraph job hangs indefinitely and is eventually killed by > JobTracker > > Hi Avery, > > I tried both the options. It does appear to be a GC problem. The problem > continues with the second option as well :(. I have attached the logs after > enabling the first set of options and using 1 worker. Would be very helpful > if you can take a look. > > This machine has 1 TB memory. We ran benchmarks of various other graph > libraries on this machine and they worked fine (even with graphs 10x larger > than the Giraph PageRank benchmark - 40 million nodes). I am sure Giraph > would work fine as well - this should not be a resource constraint. > > Thanks, > Vikesh Khanna, > Masters, Computer Science (Class of 2015) > Stanford University > > > -- > *From: *"Avery Ching" > *To: *user@giraph.apache.org > *Sent: *Thursday, April 3, 2014 7:26:56 PM > *Subject: *Re: Giraph job hangs indefinitely and is eventually killed by > JobTracker > > This is for a single worker it appears. Most likely your worker went into > GC and never returned. You can try with GC settings turned on, try adding > something like. > > -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails > -XX:+PrintGCTimeStamps -verbose:gc > > You could also try the concurrent mark/sweep collector. > > -XX:+UseConcMarkSweepGC > > Any chance you can use more workers and/or get more memory? > > Avery > > On 4/3/14, 5:46 PM, Vikesh Khanna wrote: > > @Avery, > > Thanks for the help. I checked out the task logs, and turns out there > was an exception "GC overhead limit exceeded" due to which the benchmarks > wouldn't even load the vertices. I got around it by increasing the heap > size (mapred.child.java.opts) in mapred-site.xml. The benchmark is loading > vertices now. However, the job is still getting stuck indefinitely (and > eventually killed). I have attached the small log for the map task on 1 > worker. Would really appreciate if you can help understand the cause. > > Thanks, > Vikesh Khanna, > Masters, Computer Science (Class of 2015) > Stanford University > > > -- > *From: *"Praveen kumar s.k" > > *To: *user@giraph.apache.org > *Sent: *Thursday, April 3, 2014 4:40:07 PM > *Subject: *Re: Giraph job hangs indefinitely and is eventually killed by > JobTracker > > You have given -w 30, make sure that that many number of map tasks are > configured in your cluster > > On Thu, Apr 3, 2014 at 6:24 PM, Avery Ching > wrote: > > My guess is that you don't get your resources. It would be very helpful > to > > print the master log. You can find it when the job is running to look at > > the Hadoop counters on the job UI page. > > > > Avery > > > > > > On 4/3/14, 12:49 PM, Vikesh Khanna wrote: > > > > Hi, > > > > I am running the PageRank benchmark under giraph-examples from > giraph-1.0.0 > > release. I am using the following command to run the job (as mentioned > here) > > > > vikesh@madmax > > > /lfs/madmax/0/vikesh/usr/local/giraph/giraph-examples/src/main/java/org/apache/giraph/examples > > $ $HADOOP_HOME/bin/hadoop jar > > > $GIRAPH_HOME/giraph-core/target/giraph-1.0.0-for-hadoop-0.20.203.0-jar-with-dependencies.jar > > org.apache.giraph.benchmark.PageRankBenchmark -e 1 -s 3 -v -V 5000 > -w 30 > > > > > > However, the job gets stuck at map 9% and is eventually killed by the > > JobTracker on reaching the mapred.task.timeout (default 10 minutes). I > tried > > increasing the timeout to a very large value, and the job went on for > over 8 > > hours without completion. I also tried the ShortestPathsBenchmark, which > > also fails the same way. > > > > > > Any help is appreciated. > > > > > > ** *** > > > > > > Machine details: > > > > Linux version 2.6.32-279.14.1.el6.x86_64 > > (mockbu...@c6b8.bsys.dev.centos.org) (gcc version 4.4.6 20120305 (Red > Hat > > 4.4.6-4) (GCC) ) #1 SMP Tue Nov 6 23:43:09 UTC 2012 > > > > Architecture: x86_64 > > CPU op-mode(s): 32-bit, 64-bit > > Byte Order: Little Endian > > CPU(s): 64 > > On-line CPU(s) list: 0-63 > > Thread(s) per core: 1 > > Core(s) per socket: 8 > >
Re: Breadth First Search (BFS)
Hi, I dont know what problem do you exactly solve and I have never written distributed BFS but I think that sharing queue using agreggator wont scale for larger graphs. The algorithm in video is basic its not distributed version. Lukas On 3.4.2014 15:13, ghufran malik wrote: Hi, Lukas, I believe the queue list is essential to the BFS algorithm I am trying? I am following this explanation given here: https://www.youtube.com/watch?v=zLZhSSXAwxI So for my output I want to have the vertex id followed by the number representing the order in which it was visited so vertex 5 was the start so it has a value of 0, it has neighbours 4, 8 and 2, the order in which they would be visited should be 2-4-8 so I want their values to be 1,2,3 respectively. Nishant, Yes I've seen those implementations before they were done by a student at my university some time ago, however for the BFSSO, at least, it give the depth of each vertex and not result as presented in the above video. Looking back at this algorithm though has brought into question how I originally understood how the BSP model works in Giraph. I am confused on how it works based on 1 fact, I thought every vertex was initially active and run the compute method, so why isit that after superstep 0 in this algorithm, every other vertex is not set to 1? I could be flawed in my understanding but It seems to me that this algorithm for superstep 0 sets the depth (value) for the start vertex to 0, that's fine, after that it sends a message to all vertices that are its neighbours to activate them (according to the code comments)? I thought all vertices where initially active until they vote to halt? Pregel Paper: "In superstep 0, every vertex is in the active state; all active vertices participate in the computation of any given superstep. A vertex deactivates itself by voting to halt." He then sets every other vertex value that's not the start vertex to a max integer. The supersteps after checks if the vertex value is of a max value and if it is set the value to that superstep number. So superstep 1 all the remaining vertices should be set to 1? - this assumption of mine I believe is wrong but I need help in understanding why. this was my original understanding until I ran the code on the following graph: [0,0,[[1,1],[3,3]]] [1,0,[[0,1],[2,2],[3,1]]] [2,0,[[1,2],[4,4]]] [3,0,[[0,3],[1,1],[5,0]]] [4,0,[[2,4]]] [5,0,[[3,0]]] and got the output: 52.0 01.0 21.0 10.0 31.0 42.0 Note that the start vertex id was 1. So 1 is 0 thats done if the first superstep. then messages are sent to its neighbours and it seems to me that only these are active in superstep 1 so they are given a value 1 and messages are sent to their neighbours (4 and 5). Why are 4 and 5 not active in superstep 1 as well and given a value 1? Only in superstep 2 once these vertices have received messages are they taken in to consideration and give a value 2. So in conclusion why aren't all the vertices given a value 1 in superstep 1 as I thought all vertices should be active? Unless all vertices are ONLY active in superstep 0 after which ones that do not receive a message vote to a halt? Sorry for long read, Thanks, Ghufran On Thu, Apr 3, 2014 at 11:50 AM, nishant gandhi mailto:nishantgandh...@gmail.com>> wrote: Check this out for BFS.. http://stackoverflow.com/questions/12253794/breadth-first-implentation-in-giraph-graphchi-or-pregel Nishant Gandhi M.Tech CSE IIT Patna On Thu, Apr 3, 2014 at 3:18 PM, Lukas Nalezenec mailto:lukas.naleze...@firma.seznam.cz>> wrote: Hi, It looks like you are using wrong algorithm. If you are doing simple BFS you should not need to remember vertex ids. Lukas Lukas On 2.4.2014 20:30, ghufran malik wrote: Hi I am trying to implement the BFS algorithm using Giraph 1.1.0. I have partly implemented it and am stuck on just one part. I have a list of vertex ids and I want these ids to be seen in the next superstep. Is it possible for me to just have the list in my BasicComputations class or do I need to send it to an aggregator or master class of some sort to store this list so that in the next superstep I can use this list of vertex ids in my basiccomputations class? kind regards, Ghufran
Re: Giraph job hangs indefinitely and is eventually killed by JobTracker
Hi, Any ideas why Giraph waits indefinitely? I've been stuck on this for a long time now. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Vikesh Khanna" To: user@giraph.apache.org Sent: Friday, April 4, 2014 6:06:51 AM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker Hi Avery, I tried both the options. It does appear to be a GC problem. The problem continues with the second option as well :(. I have attached the logs after enabling the first set of options and using 1 worker. Would be very helpful if you can take a look. This machine has 1 TB memory. We ran benchmarks of various other graph libraries on this machine and they worked fine (even with graphs 10x larger than the Giraph PageRank benchmark - 40 million nodes). I am sure Giraph would work fine as well - this should not be a resource constraint. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Avery Ching" To: user@giraph.apache.org Sent: Thursday, April 3, 2014 7:26:56 PM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker This is for a single worker it appears. Most likely your worker went into GC and never returned. You can try with GC settings turned on, try adding something like. -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc You could also try the concurrent mark/sweep collector. -XX:+UseConcMarkSweepGC Any chance you can use more workers and/or get more memory? Avery On 4/3/14, 5:46 PM, Vikesh Khanna wrote: @Avery, Thanks for the help. I checked out the task logs, and turns out there was an exception "GC overhead limit exceeded" due to which the benchmarks wouldn't even load the vertices. I got around it by increasing the heap size (mapred.child.java.opts) in mapred-site.xml. The benchmark is loading vertices now. However, the job is still getting stuck indefinitely (and eventually killed). I have attached the small log for the map task on 1 worker. Would really appreciate if you can help understand the cause. Thanks, Vikesh Khanna, Masters, Computer Science (Class of 2015) Stanford University - Original Message - From: "Praveen kumar s.k" To: user@giraph.apache.org Sent: Thursday, April 3, 2014 4:40:07 PM Subject: Re: Giraph job hangs indefinitely and is eventually killed by JobTracker You have given -w 30, make sure that that many number of map tasks are configured in your cluster On Thu, Apr 3, 2014 at 6:24 PM, Avery Ching wrote: > My guess is that you don't get your resources. It would be very helpful to > print the master log. You can find it when the job is running to look at > the Hadoop counters on the job UI page. > > Avery > > > On 4/3/14, 12:49 PM, Vikesh Khanna wrote: > > Hi, > > I am running the PageRank benchmark under giraph-examples from giraph-1.0.0 > release. I am using the following command to run the job (as mentioned here) > > vikesh@madmax > /lfs/madmax/0/vikesh/usr/local/giraph/giraph-examples/src/main/java/org/apache/giraph/examples > > $ $HADOOP_HOME/bin/hadoop jar > $GIRAPH_HOME/giraph-core/target/giraph-1.0.0-for-hadoop-0.20.203.0-jar-with-dependencies.jar > > org.apache.giraph.benchmark.PageRankBenchmark -e 1 -s 3 -v -V 5000 -w 30 > > > However, the job gets stuck at map 9% and is eventually killed by the > JobTracker on reaching the mapred.task.timeout (default 10 minutes). I tried > increasing the timeout to a very large value, and the job went on for over 8 > hours without completion. I also tried the ShortestPathsBenchmark, which > also fails the same way. > > > Any help is appreciated. > > > ** *** > > > Machine details: > > Linux version 2.6.32-279.14.1.el6.x86_64 > ( mockbu...@c6b8.bsys.dev.centos.org ) (gcc version 4.4.6 20120305 (Red Hat > 4.4.6-4) (GCC) ) #1 SMP Tue Nov 6 23:43:09 UTC 2012 > > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > CPU(s): 64 > On-line CPU(s) list: 0-63 > Thread(s) per core: 1 > Core(s) per socket: 8 > CPU socket(s): 8 > NUMA node(s): 8 > Vendor ID: GenuineIntel > CPU family: 6 > Model: 47 > Stepping: 2 > CPU MHz: 1064.000 > BogoMIPS: 5333.20 > Virtualization: VT-x > L1d cache: 32K > L1i cache: 32K > L2 cache: 256K > L3 cache: 24576K > NUMA node0 CPU(s): 1-8 > NUMA node1 CPU(s): 9-16 > NUMA node2 CPU(s): 17-24 > NUMA node3 CPU(s): 25-32 > NUMA node4 CPU(s): 0,33-39 > NUMA node5 CPU(s): 40-47 > NUMA node6 CPU(s): 48-55 > NUMA node7 CPU(s): 56-63 > > > I am using a pseudo-distributed Hadoop cluster on a single machine with > 64-cores. > > > *-*** > > > Thanks, > Vikesh Khanna, > Masters, Computer Science (Class of 2015) > Stanford University > > >
Re: Master/Agreggators
Hi,
You have got bug in class MyArrayListWritable in method write. Your code
writes LONG but tries to read INT.
Regards
Lukas
On 3.4.2014 18:45, ghufran malik wrote:
Sorry I by accident sent that email before finishing it.
I tested the compute method with just:
public void compute(Vertex
vertex, Iterable messages) throws IOException
{
//check if its the first superstep
if (getSuperstep() == 0)
{
if(isStart(vertex))
{
vertex.setValue(new IntWritable((int) getSuperstep()));
for (Edge edge : vertex.getEdges())
{
idQueue.addInt(edge.getTargetVertexId().get());
sendMessage(edge.getTargetVertexId(), new IntWritable(1));
}
Collections.sort(idQueue.getArrayList());
//aggregate(ID_AGG, idQueue);
}
else
{
vertex.setValue(new IntWritable(Integer.MAX_VALUE));
}
}
else { }
vertex.voteToHalt();
}
//inner class
public static class SimpleBFSMasterCompute extends MasterCompute {
public void readFields(DataInput arg0) throws IOException {
// TODO Auto-generated method stub
}
public void write(DataOutput arg0) throws IOException {
// TODO Auto-generated method stub
}
@Override
public void compute() {
// TODO Auto-generated method stub
}
@Override
public void initialize() throws InstantiationException,
IllegalAccessException {
// TODO Auto-generated method stub
registerAggregator(ID_AGG, ArrayListAggregator.class);
}
}
and it worked fine, and then tested it with the aggregate method
uncommented and produced the same log statements as before. The values
I pass into the aggregate method are:
public static final String ID_AGG = "simplemastercompute.aggregator";
private MyArrayListWritable idQueue = new MyArrayListWritable();
code:
MyArrayListWirtable class: http://pastebin.com/n4iDjp3j
ArrayListAggregator class: http://pastebin.com/z7xjpZVU
Hopefully this made my issue clearer.
Kind regards,
Ghufran
On Thu, Apr 3, 2014 at 5:34 PM, ghufran malik > wrote:
I just tested the compute method with just:
public void compute(Vertex
vertex, Iterable messages) throws IOException
{
//check if its the first superstep
if (getSuperstep() == 0)
{
if(isStart(vertex))
{
vertex.setValue(new IntWritable((int) getSuperstep()));
for (Edge edge : vertex.getEdges())
{
idQueue.addInt(edge.getTargetVertexId().get());
sendMessage(edge.getTargetVertexId(), new IntWritable(1));
}
Collections.sort(idQueue.getArrayList());
aggregate(ID_AGG, idQueue);
}
else
{
vertex.setValue(new IntWritable(Integer.MAX_VALUE));
}
}
else{}
vertex.voteToHalt();
}
On Thu, Apr 3, 2014 at 5:24 PM, ghufran malik
mailto:ghufran1ma...@gmail.com>> wrote:
After a while of those info jobs been printed this is printed
out after:
14/04/03 17:01:25 INFO zookeeper.ClientCnxn: Unable to read
additional data from server sessionid 0x145284966610002,
likely server has closed socket, closing socket connection and
attempting reconnect
14/04/03 17:01:26 INFO mapred.JobClient: map 50% reduce 0%
14/04/03 17:01:27 INFO zookeeper.ClientCnxn: Opening socket
connection to server ghufran/127.0.1.1:22181
. Will not attempt to authenticate
using SASL (unknown error)
14/04/03 17:01:27 WARN zookeeper.ClientCnxn: Session
0x145284966610002 for server null, unexpected error, closing
socket connection and attempting reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739)
at
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350)
at
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1068)
14/04/03 17:01:27 WARN zk.ZooKeeperExt: exists: Connection
loss on attempt 0, waiting 5000 msecs before retrying.
org.apache.zookeeper.KeeperException$ConnectionLossException:
KeeperErrorCode = ConnectionLoss for
/_hadoopBsp/job_201404031649_0001/_workerProgresses
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1041)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1069)
at org.apache.giraph.zk.ZooKeeperExt.exists(ZooKeeperExt.java:360)
at
org.apache.giraph.job.JobProgressTracker$2.run(JobProgressTracker.java:87)
at java.lang.Thread.run(Thread.java:744)
14/04/03 17:01:29 INFO zookeeper.ClientCnxn: Opening socket
connection to server ghufran/127.0.1.1:22181
. Will not attempt to authenticate
using SASL (unknown error)
14/04/03 17:01:29 WARN zoo
Re: Can a vertex belong to more than one partition
Hi, No, Vertex can belong only to one partition. Can you describe algorithm you are solving ? How many those vertexes belonging to all partitions you have ? Why do you need so strict partitioning ? Regards Lukas On 6.4.2014 12:38, Akshay Trivedi wrote: In order to custom partition the graph, WorkerGraphPartitioner has to be implemented. It has a method getPartitionOwner(I vertexId) which returns PartitionOwner of the vertex. I want that some vertices belong to all paritions i.e all PartitionOwners. Can anyone help me with it? Thankyou in advance Regards Akshay
