Oops, one more in the "does anybody else see this" department: - offset recovery *** FAILED *** recoveredOffsetRanges.forall(((or: (org.apache.spark.streaming.Time, Array[org.apache.spark.streaming.kafka.OffsetRange])) => earlierOffsetRangesAsSets.contains(scala.Tuple2.apply[org.apache.spark.streaming.Time, scala.collection.immutable.Set[org.apache.spark.streaming.kafka.OffsetRange]](or._1, scala.this.Predef.refArrayOps[org.apache.spark.streaming.kafka.OffsetRange](or._2).toSet[org.apache.spark.streaming.kafka.OffsetRange])))) was false Recovered ranges are not the same as the ones generated (DirectKafkaStreamSuite.scala:301)
This actually fails consistently for me too in the Kafka integration code. Not timezone related, I think. On Wed, Jun 22, 2016 at 9:02 AM, Sean Owen <so...@cloudera.com> wrote: > I'm fairly convinced this error and others that appear timestamp > related are an environment problem. This test and method have been > present for several Spark versions, without change. I reviewed the > logic and it seems sound, explicitly setting the time zone correctly. > I am not sure why it behaves differently on this machine. > > I'd give a +1 to this release if nobody else is seeing errors like > this. The sigs, hashes, other tests pass for me. > > On Tue, Jun 21, 2016 at 6:49 PM, Sean Owen <so...@cloudera.com> wrote: >> UIUtilsSuite: >> - formatBatchTime *** FAILED *** >> "2015/05/14 [14]:04:40" did not equal "2015/05/14 [21]:04:40" >> (UIUtilsSuite.scala:73) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
