[jira] [Commented] (GIRAPH-836) Delay hive preparation until after the arguments are parsed (this allows functionality such as creating a table)
[ https://issues.apache.org/jira/browse/GIRAPH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889635#comment-13889635 ] Maja Kabiljo commented on GIRAPH-836: - Assuming you verified that this works, +1 Delay hive preparation until after the arguments are parsed (this allows functionality such as creating a table) Key: GIRAPH-836 URL: https://issues.apache.org/jira/browse/GIRAPH-836 Project: Giraph Issue Type: Bug Reporter: Avery Ching Attachments: GIRAPH-836.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-811) Infinite ZooKeeper CleanUp
[
https://issues.apache.org/jira/browse/GIRAPH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889640#comment-13889640
]
Alexandre Fonseca commented on GIRAPH-811:
--
With the newest pushes to the repository this no longer seems to be a problem
(atleast I couldn't replicate it anymore with the latest trunk).
Infinite ZooKeeper CleanUp
--
Key: GIRAPH-811
URL: https://issues.apache.org/jira/browse/GIRAPH-811
Project: Giraph
Issue Type: Bug
Components: bsp, zookeeper
Affects Versions: 1.1.0
Reporter: Alexandre Fonseca
Labels: yarn
Attachments: GIRAPH-811.patch
While executing the SimpleShortestPaths example with Giraph 1.1.0-SNAPSHOT
compiled for Hadoop Yarn 2.2.0, I've noticed that the application would never
stop even after recognizing that all supersteps had completed and the output
had been written to the output directory.
Looking at the logs, I found that the BspServiceMaster is stuck at the while
loop at the end of cleanrUpZooKeeper() (BspServiceMaster.java:1729):
{code}2013-12-08 03:51:21,698 INFO [org.apache.giraph.master.MasterThread]
master.MasterThread (MasterThread.java:run(121)) - masterThread: Coordination
of superstep 3 took 0.433 seconds ended with state ALL_SUPERSTEPS_DONE and is
now on superstep 4
2013-12-08 03:51:21,699 INFO [org.apache.giraph.master.MasterThread]
master.BspServiceMaster (BspServiceMaster.java:setJobState(261)) -
setJobState:
{_stateKey:FINISHED,_applicationAttemptKey:-1,_superstepKey:-1} on
superstep 4
2013-12-08 03:51:21,753 INFO [org.apache.giraph.master.MasterThread]
master.BspServiceMaster (BspServiceMaster.java:cleanup(1836)) - cleanup:
Notifying master its okay to cleanup with
/_hadoopBsp/giraph_yarn_application_1386468390622_0005/_cleanedUpDir/0_master
2013-12-08 03:51:21,790 INFO [org.apache.giraph.master.MasterThread]
master.BspServiceMaster (BspServiceMaster.java:cleanUpZooKeeper(1711)) -
cleanUpZooKeeper: Node
/_hadoopBsp/giraph_yarn_application_1386468390622_0005/_cleanedUpDir already
exists, no need to create.
2013-12-08 03:51:21,792 INFO [org.apache.giraph.master.MasterThread]
bsp.BspInputFormat (BspInputFormat.java:getMaxTasks(64)) - getMaxTasks: Max
workers = 1, split master/worker = true, is YARN-only job = true, total max
tasks = 1
2013-12-08 03:51:21,792 INFO [org.apache.giraph.master.MasterThread]
master.BspServiceMaster (BspServiceMaster.java:cleanUpZooKeeper(1735)) -
cleanUpZooKeeper: Got 2 of 1 desired children from
/_hadoopBsp/giraph_yarn_application_1386468390622_0005/_cleanedUpDir
2013-12-08 03:51:21,793 INFO [org.apache.giraph.master.MasterThread]
master.BspServiceMaster (BspServiceMaster.java:cleanUpZooKeeper(1744)) -
cleanedUpZooKeeper: Waiting for the children of
/_hadoopBsp/giraph_yarn_application_1386468390622_0005/_cleanedUpDir to
change since only got 2 nodes.{code}
As the last 2 entries show, instead of registering just 1 task ending, it
registers 2 and thus it misses the condition on line 1740.
One solution would be to change the == in line 1740 to a =. However, the
actual issue seems to reside with the BspInputFormat.getMaxTasks()
(BspInputFormat.java:51). This function assumes that in a pure yarn execution
the total number of tasks will be equal to the maximum number of workers.
However, based on GiraphApplicationMaster:167, this is not the case. An extra
Master task is launched in addition to all the Worker tasks.
BspInputFormat.getMaxTasks() should then return maxWorkers + 1 in the case of
a pure yarn execution.
Compilation:
{code}mvn -Phadoop_yarn -Dhadoop.version=2.2.0 -DskipTests compile{code}
Execution command:
{code}$HADOOP_PREFIX/bin/hadoop jar
~/Projects/giraph/giraph-examples/target/giraph-examples-1.1.0-SNAPSHOT-for-hadoop-2.2.0-jar-with-dependencies.jar
org.apache.giraph.GiraphRunner
org.apache.giraph.examples.SimpleShortestPathsComputation -vif
org.apache.giraph.io.formats.JsonLongDoubleFloatDoubleVertexInputFormat -vip
giraph/input/tiny_graph.txt -vof
org.apache.giraph.io.formats.IdWithValueTextOutputFormat -op
giraph/output/shortestpahts -w 1 -ca giraph.zkList=localhost:2181 -yj
giraph-examples-1.1.0-SNAPSHOT-for-hadoop-2.2.0-jar-with-dependencies.jar{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (GIRAPH-835) org.apache.giraph.hive.input.CheckInputTest Fails because JobProgressTracker doesn't check null
[ https://issues.apache.org/jira/browse/GIRAPH-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889645#comment-13889645 ] Maja Kabiljo commented on GIRAPH-835: - +1, thanks, committing org.apache.giraph.hive.input.CheckInputTest Fails because JobProgressTracker doesn't check null Key: GIRAPH-835 URL: https://issues.apache.org/jira/browse/GIRAPH-835 Project: Giraph Issue Type: Bug Components: graph Affects Versions: 1.1.0 Reporter: Akila Wajirasena Fix For: 1.1.0 Attachments: GIRAPH-835.patch org.apache.giraph.hive.input.CheckInputTest Fails because JobProgressTracker doesn't check null string returned from CounterUtils.waitAndGetCounterNameFromGroup() --- Test set: org.apache.giraph.hive.input.CheckInputTest --- Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 35.864 sec FAILURE! testCheckJobThrows(org.apache.giraph.hive.input.CheckInputTest) Time elapsed: 15.001 sec ERROR! java.lang.NullPointerException at org.apache.zookeeper.ClientCnxn.init(ClientCnxn.java:360) at org.apache.zookeeper.ClientCnxn.init(ClientCnxn.java:331) at org.apache.zookeeper.ZooKeeper.init(ZooKeeper.java:377) at org.apache.giraph.zk.ZooKeeperExt.init(ZooKeeperExt.java:114) at org.apache.giraph.job.JobProgressTracker.init(JobProgressTracker.java:69) at org.apache.giraph.job.GiraphJob.run(GiraphJob.java:255) at org.apache.giraph.utils.InternalVertexRunner.run(InternalVertexRunner.java:178) at org.apache.giraph.hive.input.CheckInputTest.testCheckJobThrows(CheckInputTest.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103) at org.apache.maven.surefire.Surefire.run(Surefire.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-835) org.apache.giraph.hive.input.CheckInputTest Fails because JobProgressTracker doesn't check null
[ https://issues.apache.org/jira/browse/GIRAPH-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889650#comment-13889650 ] Hudson commented on GIRAPH-835: --- FAILURE: Integrated in Giraph-trunk-Commit #1402 (See [https://builds.apache.org/job/Giraph-trunk-Commit/1402/]) GIRAPH-835: org.apache.giraph.hive.input.CheckInputTest Fails because JobProgressTracker doesn't check null (akila via majakabiljo) (majakabiljo: http://git-wip-us.apache.org/repos/asf?p=giraph.gita=commith=763621a45cd7812ee968f78961775f85f5e95cb2) * giraph-core/src/main/java/org/apache/giraph/job/JobProgressTracker.java * CHANGELOG org.apache.giraph.hive.input.CheckInputTest Fails because JobProgressTracker doesn't check null Key: GIRAPH-835 URL: https://issues.apache.org/jira/browse/GIRAPH-835 Project: Giraph Issue Type: Bug Components: graph Affects Versions: 1.1.0 Reporter: Akila Wajirasena Fix For: 1.1.0 Attachments: GIRAPH-835.patch org.apache.giraph.hive.input.CheckInputTest Fails because JobProgressTracker doesn't check null string returned from CounterUtils.waitAndGetCounterNameFromGroup() --- Test set: org.apache.giraph.hive.input.CheckInputTest --- Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 35.864 sec FAILURE! testCheckJobThrows(org.apache.giraph.hive.input.CheckInputTest) Time elapsed: 15.001 sec ERROR! java.lang.NullPointerException at org.apache.zookeeper.ClientCnxn.init(ClientCnxn.java:360) at org.apache.zookeeper.ClientCnxn.init(ClientCnxn.java:331) at org.apache.zookeeper.ZooKeeper.init(ZooKeeper.java:377) at org.apache.giraph.zk.ZooKeeperExt.init(ZooKeeperExt.java:114) at org.apache.giraph.job.JobProgressTracker.init(JobProgressTracker.java:69) at org.apache.giraph.job.GiraphJob.run(GiraphJob.java:255) at org.apache.giraph.utils.InternalVertexRunner.run(InternalVertexRunner.java:178) at org.apache.giraph.hive.input.CheckInputTest.testCheckJobThrows(CheckInputTest.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103) at org.apache.maven.surefire.Surefire.run(Surefire.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (GIRAPH-788) Giraph job suspends with exceptions when out-of-core options are set
[
https://issues.apache.org/jira/browse/GIRAPH-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Fonseca updated GIRAPH-788:
-
Attachment: GIRAPH-788.patch
Stumbled across this same issue today with exactly the same stacktrace.
Function getOrCreatePartition(id) in DiskBackedPartitionStore:228-238 is the
parent in the stacktrace of the NPR. Looking at the code:
{code:java}
PartitionI, V, E partition =
pool.submit(new GetPartition(id)).get();
if (partition == null) {
PartitionI, V, E newPartition =
conf.createPartition(id, context);
pool.submit(
new AddPartition(id, newPartition)).get();
return newPartition;
} else {
return partition;
}
{/code}
it is obvious that the intent is getting a partition if it exists or adding a
new one if it doesn't. However, in the call() method of GetPartition
(DiskBackedPartitionStore:695), the states HashMap is accessed directly without
any ID check. Since states are only created for existing partitions, the result
of this access is a null pointer. Switching on that null pointer causes the NPR:
{code:java}
while (partition == null) {
wLock.lock();
try {
State pState = states.get(id);
switch (pState) {
{/code}
By adding a check before this direct access for the existence of the partition,
I was able to circumvent the NPR and obtain the expected result. This patch
implements that check and was tested against a 5-node Hadoop 2.2.0 cluster
using both MR2 and YARN executions.
Giraph job suspends with exceptions when out-of-core options are set
Key: GIRAPH-788
URL: https://issues.apache.org/jira/browse/GIRAPH-788
Project: Giraph
Issue Type: Bug
Components: mapreduce
Affects Versions: 1.0.0
Environment: uses hadoop 0.20.203.0 with 32 cluster nodes
Giraph release-1.0 pulled Oct. 29. 2013.
Reporter: Byungnam Lim
Attachments: GIRAPH-788.patch
When I run my code with out-of-core graph/message options OFF, it's fine. But
when out-of-core graph/message options ON, then some workers give me
exception messages like below and whole tasks suspends.
{noformat}
java.lang.IllegalStateException: run: Caught an unrecoverable exception
waitFor: ExecutionException occurred while waiting for
org.apache.giraph.utils.ProgressableUtils$FutureWaitable@3c7659ab
at org.apache.giraph.graph.GraphMapper.run(GraphMapper.java:101)
at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:763)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:369)
at org.apache.hadoop.mapred.Child$4.run(Child.java:259)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1059)
at org.apache.hadoop.mapred.Child.main(Child.java:253)
Caused by: java.lang.IllegalStateException: waitFor: ExecutionException
occurred while waiting for
org.apache.giraph.utils.ProgressableUtils$FutureWaitable@3c7659ab
at
org.apache.giraph.utils.ProgressableUtils.waitFor(ProgressableUtils.java:181)
at
org.apache.giraph.utils.ProgressableUtils.waitForever(ProgressableUtils.java:139)
at
org.apache.giraph.utils.ProgressableUtils.waitForever(ProgressableUtils.java:124)
at
org.apache.giraph.utils.ProgressableUtils.getFutureResult(ProgressableUtils.java:87)
at
org.apache.giraph.utils.ProgressableUtils.getResultsWithNCallables(ProgressableUtils.java:221)
at
org.apache.giraph.worker.BspServiceWorker.loadInputSplits(BspServiceWorker.java:283)
at
org.apache.giraph.worker.BspServiceWorker.loadVertices(BspServiceWorker.java:327)
at
org.apache.giraph.worker.BspServiceWorker.setup(BspServiceWorker.java:508)
at
org.apache.giraph.graph.GraphTaskManager.execute(GraphTaskManager.java:246)
at org.apache.giraph.graph.GraphMapper.run(GraphMapper.java:91)
... 7 more
Caused by: java.util.concurrent.ExecutionException:
java.lang.IllegalStateException: getOrCreatePartition: cannot retrieve
partition 6
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:262)
at java.util.concurrent.FutureTask.get(FutureTask.java:119)
at
org.apache.giraph.utils.ProgressableUtils$FutureWaitable.waitFor(ProgressableUtils.java:300)
at
org.apache.giraph.utils.ProgressableUtils.waitFor(ProgressableUtils.java:173)
... 16 more
Caused by: java.lang.IllegalStateException: getOrCreatePartition: cannot
retrieve partition 6
at
[jira] [Commented] (GIRAPH-839) NettyWorkerAggregatorRequestProcessor tries to reuse request objects
[ https://issues.apache.org/jira/browse/GIRAPH-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889658#comment-13889658 ] Maja Kabiljo commented on GIRAPH-839: - Thanks, +1 NettyWorkerAggregatorRequestProcessor tries to reuse request objects Key: GIRAPH-839 URL: https://issues.apache.org/jira/browse/GIRAPH-839 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Attachments: GIRAPH-839.patch I was working on upgrading netty to 4.0.14.Final. It is mostly done, after some polishing I will submit a patch for that soon. While working on the above, I discovered a bug in NettyWorkerAggregatorRequestProcessor. The distributeAggregators method is reusing SendAggregatorsToWorkerRequest objects, which is incorrect since each task has a different task id (potentially a different) request id. It does not cause any problem with current netty but in the new version I guess due to delayed serialization the object cannot be reused. Anyway, moving it inside the for loop does not cause any issues with current netty as well. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-838) setup time total time counter also include time spent waiting for machines
[ https://issues.apache.org/jira/browse/GIRAPH-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889676#comment-13889676 ] Maja Kabiljo commented on GIRAPH-838: - +1, committing setup time total time counter also include time spent waiting for machines Key: GIRAPH-838 URL: https://issues.apache.org/jira/browse/GIRAPH-838 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Minor Attachments: GIRAPH-838.patch, first.rtf, second.rtf Currently the setup time total time counters also include time spent waiting to acquire machines in the cluster. Because of this the total execution time shown on job page is inaccurate. Total time should not include the time spend waiting for cluster resources. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-839) NettyWorkerAggregatorRequestProcessor tries to reuse request objects
[ https://issues.apache.org/jira/browse/GIRAPH-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889687#comment-13889687 ] Hudson commented on GIRAPH-839: --- ABORTED: Integrated in Giraph-trunk-Commit #1403 (See [https://builds.apache.org/job/Giraph-trunk-Commit/1403/]) GIRAPH-839: NettyWorkerAggregatorRequestProcessor tries to reuse request objects (pavanka via majakabiljo) (majakabiljo: http://git-wip-us.apache.org/repos/asf?p=giraph.gita=commith=9325fa9869c2604172576f89311308915ebb416d) * CHANGELOG * giraph-core/src/main/java/org/apache/giraph/comm/netty/NettyWorkerAggregatorRequestProcessor.java NettyWorkerAggregatorRequestProcessor tries to reuse request objects Key: GIRAPH-839 URL: https://issues.apache.org/jira/browse/GIRAPH-839 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Attachments: GIRAPH-839.patch I was working on upgrading netty to 4.0.14.Final. It is mostly done, after some polishing I will submit a patch for that soon. While working on the above, I discovered a bug in NettyWorkerAggregatorRequestProcessor. The distributeAggregators method is reusing SendAggregatorsToWorkerRequest objects, which is incorrect since each task has a different task id (potentially a different) request id. It does not cause any problem with current netty but in the new version I guess due to delayed serialization the object cannot be reused. Anyway, moving it inside the for loop does not cause any issues with current netty as well. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-840) Upgrade to netty 4
[ https://issues.apache.org/jira/browse/GIRAPH-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889706#comment-13889706 ] Avery Ching commented on GIRAPH-840: This is awesome work. Eugene, would you mind taking a look at the patch to see is SASL works? Upgrade to netty 4 -- Key: GIRAPH-840 URL: https://issues.apache.org/jira/browse/GIRAPH-840 Project: Giraph Issue Type: Improvement Reporter: Pavan Kumar Assignee: Pavan Kumar Off late netty 4 has earned so much praise in the community. For example, https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead A switch to netty 4 enables a significant reduction in gc pressure and also huge performance gains. I started working on this last Sunday and have a patch that shows performance gains on the order of 15-25% (total execution time) for some applications at Facebook. However, I only tested it with hadoop_facebook. So there might be issues with SASL path. I will release the patch today and want to open up a discussion if anyone is using the secure feature anymore. If not we can just deprecate it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Review Request 17528: GIRAPH-833
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17528/#review33446 --- Ship it! Thanks! - Maja Kabiljo On Jan. 30, 2014, 7:58 a.m., Avery Ching wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17528/ --- (Updated Jan. 30, 2014, 7:58 a.m.) Review request for giraph. Bugs: GIRAPH-833 https://issues.apache.org/jira/browse/GIRAPH-833 Repository: giraph-git Description --- Upgrade ZooKeeper 3.3.3 - 3.4.5 Upgrade HBase 0.90.5- 0.94.16 Fixed giraph-hbase guava dependency Factored out commmon logic to start standalone zookeeper in InternalVertexRunner.java Fixed TestHBaseRootMarkerVertextFormat test to support the newer versions of ZooKeeper/HBase Disabled giraph-hbase for the Hadoop Facebook profile (never used and hard to work with the Facebook Hadoop) Diffs - giraph-core/pom.xml 2a1e8383650a420f8625ab4a97e0d86272a3b4ca giraph-core/src/main/java/org/apache/giraph/utils/InternalVertexRunner.java 3f49395c9bdc03d1ec7431b25188faaff1230616 giraph-core/src/test/java/org/apache/giraph/io/TestJsonBase64Format.java 3b0dc63707e84cfb7802affe1fe947ea847fbd8b giraph-examples/pom.xml 50b1c47b5554d11d0fd4e6bcf390596175116dd6 giraph-gora/pom.xml f192eb64e2e29a440fca3ed208e6e56419aaa7b4 giraph-hbase/pom.xml a663c09932f305134137a087cdd37c8f25d75bfe giraph-hbase/src/test/java/org/apache/giraph/io/hbase/TestHBaseRootMarkerVertextFormat.java 02d2754831017cacb8f40e5675db1ae0293ad70e giraph-hcatalog/pom.xml cba9bc9f758cbe46af0010eff54f55f81a191fb3 giraph-hive/pom.xml df122d3cddbbfbeb486af3429a841ca6bda7dd02 giraph-rexster/giraph-rexster-io/pom.xml 3553552821e42b583349ae613d8e701edb9e81c8 pom.xml efad0def73b4d1bbb63407f1e804158a3360070e Diff: https://reviews.apache.org/r/17528/diff/ Testing --- mvn clean verify Thanks, Avery Ching
[jira] [Commented] (GIRAPH-838) setup time total time counter also include time spent waiting for machines
[ https://issues.apache.org/jira/browse/GIRAPH-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889709#comment-13889709 ] Hudson commented on GIRAPH-838: --- SUCCESS: Integrated in Giraph-trunk-Commit #1404 (See [https://builds.apache.org/job/Giraph-trunk-Commit/1404/]) GIRAPH-838: setup time total time counter also include time spent waiting for machines (pavanka via majakabiljo) (majakabiljo: http://git-wip-us.apache.org/repos/asf?p=giraph.gita=commith=4d520645ff53b9a354fef57074c7661f3bc46e39) * giraph-core/src/main/java/org/apache/giraph/counters/GiraphTimers.java * giraph-core/src/main/java/org/apache/giraph/master/BspServiceMaster.java * giraph-core/src/main/java/org/apache/giraph/master/MasterThread.java * CHANGELOG * giraph-core/src/main/java/org/apache/giraph/bsp/CentralizedServiceMaster.java setup time total time counter also include time spent waiting for machines Key: GIRAPH-838 URL: https://issues.apache.org/jira/browse/GIRAPH-838 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Minor Attachments: GIRAPH-838.patch, first.rtf, second.rtf Currently the setup time total time counters also include time spent waiting to acquire machines in the cluster. Because of this the total execution time shown on job page is inaccurate. Total time should not include the time spend waiting for cluster resources. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (GIRAPH-842) option to dump histogram of memory usage when heap is low on memory
Pavan Kumar created GIRAPH-842: -- Summary: option to dump histogram of memory usage when heap is low on memory Key: GIRAPH-842 URL: https://issues.apache.org/jira/browse/GIRAPH-842 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Minor Currently we are left in blind for jobs that OOM, it would be helpful if we can do a jmap -histo dump when heap has very little free space left. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (GIRAPH-842) option to dump histogram of memory usage when heap is low on memory
[ https://issues.apache.org/jira/browse/GIRAPH-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar updated GIRAPH-842: --- Attachment: master-stderr worker-stderr attaching stderr files from a worker and master to show how the histogram dump looks like (and also see that the code actually works) option to dump histogram of memory usage when heap is low on memory --- Key: GIRAPH-842 URL: https://issues.apache.org/jira/browse/GIRAPH-842 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Minor Attachments: GIRAPH-842.patch, master-stderr, worker-stderr Currently we are left in blind for jobs that OOM, it would be helpful if we can do a jmap -histo dump when heap has very little free space left. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-842) option to dump histogram of memory usage when heap is low on memory
[ https://issues.apache.org/jira/browse/GIRAPH-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889829#comment-13889829 ] Pavan Kumar commented on GIRAPH-842: pulled latest trunk (after prev 2 commits) and ran mvn clean verify. it succeeds. option to dump histogram of memory usage when heap is low on memory --- Key: GIRAPH-842 URL: https://issues.apache.org/jira/browse/GIRAPH-842 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Minor Attachments: GIRAPH-842.patch, master-stderr, worker-stderr Currently we are left in blind for jobs that OOM, it would be helpful if we can do a jmap -histo dump when heap has very little free space left. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (GIRAPH-843) remove rexter from hadoop_facebook profile
Pavan Kumar created GIRAPH-843: -- Summary: remove rexter from hadoop_facebook profile Key: GIRAPH-843 URL: https://issues.apache.org/jira/browse/GIRAPH-843 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Trivial mvn clean verify -Phadoop_facebook fails on rexter-io test with the message that unable to launch tests. It needs to be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (GIRAPH-843) remove rexter from hadoop_facebook profile
[ https://issues.apache.org/jira/browse/GIRAPH-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar updated GIRAPH-843: --- Attachment: GIRAPH-843.patch remove rexter from hadoop_facebook profile -- Key: GIRAPH-843 URL: https://issues.apache.org/jira/browse/GIRAPH-843 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Trivial Attachments: GIRAPH-843.patch mvn clean verify -Phadoop_facebook fails on rexter-io test with the message that unable to launch tests. It needs to be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
RE: [jira] [Commented] (GIRAPH-839) NettyWorkerAggregatorRequestProcessor tries to reuse request objects
It succeeds on the next commit. I also verified that on my computer that it
succeeds. This must be transient issue. Please tell if otherwise.
Date: Tue, 4 Feb 2014 05:46:11 +
From: j...@apache.org
To: giraph-...@incubator.apache.org
Subject: [jira] [Commented] (GIRAPH-839)
NettyWorkerAggregatorRequestProcessor tries to reuse request objects
[
https://issues.apache.org/jira/browse/GIRAPH-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890413#comment-13890413
]
Eugene Koontz commented on GIRAPH-839:
--
Hm, looks like the build failed because a test couldn't connect to ZooKeeper?
https://builds.apache.org/job/Giraph-trunk-Commit/1403/consoleText (warning:
big output)
{code}
14/02/03 17:53:01 INFO zookeeper.ClientCnxn: Opening socket connection to
server localhost/127.0.0.1:22182
14/02/03 17:53:01 WARN zookeeper.ClientCnxn: Session 0x143f8e19d350002 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:708)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1119)
14/02/03 17:53:02 INFO server.SessionTrackerImpl: SessionTrackerImpl exited
loop!
{code}
NettyWorkerAggregatorRequestProcessor tries to reuse request objects
Key: GIRAPH-839
URL: https://issues.apache.org/jira/browse/GIRAPH-839
Project: Giraph
Issue Type: Bug
Reporter: Pavan Kumar
Assignee: Pavan Kumar
Attachments: GIRAPH-839.patch
I was working on upgrading netty to 4.0.14.Final. It is mostly done, after
some polishing I will submit a patch for that soon.
While working on the above, I discovered a bug in
NettyWorkerAggregatorRequestProcessor. The distributeAggregators method is
reusing SendAggregatorsToWorkerRequest objects, which is incorrect since
each task has a different task id (potentially a different) request id.
It does not cause any problem with current netty but in the new version I
guess due to delayed serialization the object cannot be reused.
Anyway, moving it inside the for loop does not cause any issues with
current netty as well.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (GIRAPH-844) TextInputFormat for SimpleShortestPaths
Sebastian Schelter created GIRAPH-844: - Summary: TextInputFormat for SimpleShortestPaths Key: GIRAPH-844 URL: https://issues.apache.org/jira/browse/GIRAPH-844 Project: Giraph Issue Type: Improvement Components: examples Reporter: Sebastian Schelter Fix For: 1.1.0 It seems we lack an appropriate InputFormat for org.apache.giraph.examples.SimpleShortestPathsComputation. We should add a LongDoubleFloatDoubleInputFormat or change the signature of SimpleShortestPathsComputation so that its compatible with an existing InputFormat -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-840) Upgrade to netty 4
[
https://issues.apache.org/jira/browse/GIRAPH-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890441#comment-13890441
]
Eugene Koontz commented on GIRAPH-840:
--
Pavan,
Impressive, looks like a lot of work went into this!
Avery,
{{mvn -P2.2.0 test}}
and
{{mvn -Phadoop_yarn -Dhadoop.version=2.2.0 test}}
work for me, provided I use Pavan's patch from this issue together with my
GIRAPH-841 patch.
I have not yet looked at the SASL-specific tests, but I assume those passed if
the whole thing passes. Will look more at it later tonight.
Upgrade to netty 4
--
Key: GIRAPH-840
URL: https://issues.apache.org/jira/browse/GIRAPH-840
Project: Giraph
Issue Type: Improvement
Reporter: Pavan Kumar
Assignee: Pavan Kumar
Off late netty 4 has earned so much praise in the community. For example,
https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead
A switch to netty 4 enables a significant reduction in gc pressure and also
huge performance gains. I started working on this last Sunday and have a
patch that shows performance gains on the order of 15-25% (total execution
time) for some applications at Facebook. However, I only tested it with
hadoop_facebook. So there might be issues with SASL path.
I will release the patch today and want to open up a discussion if anyone is
using the secure feature anymore. If not we can just deprecate it.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: Review Request 17646: GIRAPH-841: fix missing munge symbols error for non-munge-using profiles
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17646/ --- (Updated Feb. 4, 2014, 7:09 a.m.) Review request for giraph. Changes --- make subject more concise Summary (updated) - GIRAPH-841: fix missing munge symbols error for non-munge-using profiles Repository: giraph-git Description --- A simple fix is to globally define munge.symbols to a value that is never used otherwise, e.g. NO_MUNGE_SYMBOLS. This will be overridden by profiles that need munge.symbols to be set to a specific value. Diffs - pom.xml efad0de Diff: https://reviews.apache.org/r/17646/diff/ Testing --- Successfully runs mvn -P2.2.0 test and mvn test (default profile of Hadoop 0.20.203). Thanks, Eugene Koontz
[jira] [Updated] (GIRAPH-841) GIRAPH-841: fix missing munge symbols error for non-munge-using profiles
[ https://issues.apache.org/jira/browse/GIRAPH-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eugene Koontz updated GIRAPH-841: - Summary: GIRAPH-841: fix missing munge symbols error for non-munge-using profiles (was: mvn -P2.2.0 compile fails with The parameters 'symbols' for goal org.sonatype.plugins:munge-maven-plugin:1.0:munge are missing or invalid) GIRAPH-841: fix missing munge symbols error for non-munge-using profiles Key: GIRAPH-841 URL: https://issues.apache.org/jira/browse/GIRAPH-841 Project: Giraph Issue Type: Bug Components: conf and scripts Affects Versions: 1.1.0 Reporter: Eugene Koontz Fix For: 1.1.0 A simple fix is to globally define munge.symbols to a value that is never used otherwise, e.g. NO_MUNGE_SYMBOLS. This will be overridden by profiles that need munge.symbols to be set to a specific value. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-843) remove rexter from hadoop_facebook profile
[ https://issues.apache.org/jira/browse/GIRAPH-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890468#comment-13890468 ] Avery Ching commented on GIRAPH-843: +1, committing. remove rexter from hadoop_facebook profile -- Key: GIRAPH-843 URL: https://issues.apache.org/jira/browse/GIRAPH-843 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Trivial Attachments: GIRAPH-843.patch mvn clean verify -Phadoop_facebook fails on rexter-io test with the message that unable to launch tests. It needs to be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-840) Upgrade to netty 4
[ https://issues.apache.org/jira/browse/GIRAPH-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890471#comment-13890471 ] Avery Ching commented on GIRAPH-840: Thanks Eugene! Upgrade to netty 4 -- Key: GIRAPH-840 URL: https://issues.apache.org/jira/browse/GIRAPH-840 Project: Giraph Issue Type: Improvement Reporter: Pavan Kumar Assignee: Pavan Kumar Off late netty 4 has earned so much praise in the community. For example, https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead A switch to netty 4 enables a significant reduction in gc pressure and also huge performance gains. I started working on this last Sunday and have a patch that shows performance gains on the order of 15-25% (total execution time) for some applications at Facebook. However, I only tested it with hadoop_facebook. So there might be issues with SASL path. I will release the patch today and want to open up a discussion if anyone is using the secure feature anymore. If not we can just deprecate it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-843) remove rexter from hadoop_facebook profile
[ https://issues.apache.org/jira/browse/GIRAPH-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890473#comment-13890473 ] Hudson commented on GIRAPH-843: --- FAILURE: Integrated in Giraph-trunk-Commit #1405 (See [https://builds.apache.org/job/Giraph-trunk-Commit/1405/]) GIRAPH-843: remove rexter from hadoop_facebook profile (pavanka via aching) (aching: http://git-wip-us.apache.org/repos/asf?p=giraph.gita=commith=af1c05d8cfb1205fde974845d05805871ec31aa7) * CHANGELOG * pom.xml remove rexter from hadoop_facebook profile -- Key: GIRAPH-843 URL: https://issues.apache.org/jira/browse/GIRAPH-843 Project: Giraph Issue Type: Bug Reporter: Pavan Kumar Assignee: Pavan Kumar Priority: Trivial Attachments: GIRAPH-843.patch mvn clean verify -Phadoop_facebook fails on rexter-io test with the message that unable to launch tests. It needs to be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (GIRAPH-845) Fix builds on builds.apache.org
Eugene Koontz created GIRAPH-845: Summary: Fix builds on builds.apache.org Key: GIRAPH-845 URL: https://issues.apache.org/jira/browse/GIRAPH-845 Project: Giraph Issue Type: Bug Components: build Reporter: Eugene Koontz Looks like all of the giraph builds are failing right now (see screenshot). Let's get these blue again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (GIRAPH-845) Fix builds on builds.apache.org
[ https://issues.apache.org/jira/browse/GIRAPH-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eugene Koontz updated GIRAPH-845: - Attachment: Screen Shot 2014-02-03 at 11.46.15 PM.png Fix builds on builds.apache.org --- Key: GIRAPH-845 URL: https://issues.apache.org/jira/browse/GIRAPH-845 Project: Giraph Issue Type: Bug Components: build Reporter: Eugene Koontz Assignee: Eugene Koontz Attachments: Screen Shot 2014-02-03 at 11.46.15 PM.png Looks like all of the giraph builds are failing right now (see screenshot). Let's get these blue again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (GIRAPH-845) Fix builds on builds.apache.org
[ https://issues.apache.org/jira/browse/GIRAPH-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eugene Koontz reassigned GIRAPH-845: Assignee: Eugene Koontz Fix builds on builds.apache.org --- Key: GIRAPH-845 URL: https://issues.apache.org/jira/browse/GIRAPH-845 Project: Giraph Issue Type: Bug Components: build Reporter: Eugene Koontz Assignee: Eugene Koontz Attachments: Screen Shot 2014-02-03 at 11.46.15 PM.png Looks like all of the giraph builds are failing right now (see screenshot). Let's get these blue again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (GIRAPH-840) Upgrade to netty 4
[
https://issues.apache.org/jira/browse/GIRAPH-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890477#comment-13890477
]
Eugene Koontz commented on GIRAPH-840:
--
Gettting a failure with {{mvn -Phadoop_1.0 clean test}}:
https://gist.github.com/ekoontz/8799669
Upgrade to netty 4
--
Key: GIRAPH-840
URL: https://issues.apache.org/jira/browse/GIRAPH-840
Project: Giraph
Issue Type: Improvement
Reporter: Pavan Kumar
Assignee: Pavan Kumar
Off late netty 4 has earned so much praise in the community. For example,
https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead
A switch to netty 4 enables a significant reduction in gc pressure and also
huge performance gains. I started working on this last Sunday and have a
patch that shows performance gains on the order of 15-25% (total execution
time) for some applications at Facebook. However, I only tested it with
hadoop_facebook. So there might be issues with SASL path.
I will release the patch today and want to open up a discussion if anyone is
using the secure feature anymore. If not we can just deprecate it.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (GIRAPH-845) Fix builds on builds.apache.org
[ https://issues.apache.org/jira/browse/GIRAPH-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890478#comment-13890478 ] Sebastian Schelter commented on GIRAPH-845: --- Build fails on my local machine too, org.apache.giraph.io.hbase.TestHBaseRootMarkerVertextFormat seems to be the problem: testHBaseInputOutput(org.apache.giraph.io.hbase.TestHBaseRootMarkerVertextFormat) Time elapsed: 601.806 sec ERROR! org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find region for after 10 tries. at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:888) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:797) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:766) at org.apache.hadoop.hbase.client.HTable.init(HTable.java:189) at org.apache.hadoop.hbase.HBaseTestingUtility.restartHBaseCluster(HBaseTestingUtility.java:395) at org.apache.giraph.io.hbase.TestHBaseRootMarkerVertextFormat.testHBaseInputOutput(TestHBaseRootMarkerVertextFormat.java:139) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103) at org.apache.maven.surefire.Surefire.run(Surefire.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) Fix builds on builds.apache.org --- Key: GIRAPH-845 URL: https://issues.apache.org/jira/browse/GIRAPH-845 Project: Giraph Issue Type: Bug Components: build Reporter: Eugene Koontz Assignee: Eugene Koontz Attachments: Screen Shot 2014-02-03 at 11.46.15 PM.png Looks like all of the giraph builds are failing right now (see screenshot). Let's get these blue again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
