it seems to be Spark (spurious) failure, unable to open broadcast variable handle. It would be nice to understand more why it happened, either we are doing something wrong causing something to race, or it is something bad with this version of Spark (or even build host setup?) causing this.
It is unlikely though it is our unit test setup, as we basically just ripped it off unit testing in Spark. We are also not running any parallel sessions here. I think (but not sure) i saw it happened once before after we switched to 1.0, perhaps in my local runs, but never once we were on 0.9. Sean, or anyone else, if you have any thoughts I'd appreciate sharing. On Thu, Aug 28, 2014 at 10:57 PM, Sean Owen (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/MAHOUT-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14114893#comment-14114893 > ] > > Sean Owen commented on MAHOUT-1610: > ----------------------------------- > > I forgot to modify CHANGELOG, so fixed that in an extra commit. The > original Hudson tests passed, so I can only assume this change to just the > CHANGELOG file can't have broken something, and that this is a spurious > failure. > > > Tests can be made more robust to pass in Java 8 > > ----------------------------------------------- > > > > Key: MAHOUT-1610 > > URL: https://issues.apache.org/jira/browse/MAHOUT-1610 > > Project: Mahout > > Issue Type: Bug > > Components: Integration > > Affects Versions: 0.9 > > Environment: Java 1.8.0_11 OS X 10.9.4 > > Reporter: Sean Owen > > Assignee: Sean Owen > > Priority: Minor > > Labels: java8, tests > > Fix For: 1.0 > > > > > > Right now, several tests don't seem to pass when run with Java 8 (at > least on Java 8). The failures are benign, and just due to tests looking > for too-specific values or expecting things like a certain ordering of > hashmaps. > > The tests can easily be made to pass both Java 8 and Java 6/7 at the > same time by either relaxing the tests in a principled way, or accepting > either output of two equally valid ones as correct. > > (There's also one curious compilation failure in Java 8, related to > generics. It is fixable by changing to a more explicit declaration that > should be equivalent. It should be entirely equivalent at compile time, and > of course, at run time. I am not sure it's not just a javac bug, but, might > as well work around when it's so easy.) > > > > -- > This message was sent by Atlassian JIRA > (v6.2#6252) >
