HeartSaVioR commented on a change in pull request #26416: [SPARK-29779][CORE] Compact old event log files and cleanup URL: https://github.com/apache/spark/pull/26416#discussion_r355284671
########## File path: core/src/main/scala/org/apache/spark/deploy/history/EventFilter.scala ########## @@ -0,0 +1,226 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.spark.deploy.history + +import java.util.ServiceLoader + +import scala.collection.JavaConverters._ +import scala.io.{Codec, Source} +import scala.util.control.NonFatal + +import org.apache.hadoop.fs.{FileSystem, Path} +import org.json4s.jackson.JsonMethods.parse + +import org.apache.spark.internal.Logging +import org.apache.spark.scheduler._ +import org.apache.spark.util.{JsonProtocol, Utils} + +/** + * EventFilterBuilder provides the interface to gather the information from events being received + * by [[SparkListenerInterface]], and create a new [[EventFilter]] instance which leverages + * information gathered to decide whether the event should be filtered or not. + */ +private[spark] trait EventFilterBuilder extends SparkListenerInterface { + def createFilter(): EventFilter +} + +object EventFilterBuilder { + /** + * Loads all available EventFilterBuilders in classloader via ServiceLoader, and initializes + * them via replaying events in given files. + */ + def initializeBuilders(fs: FileSystem, files: Seq[Path]): Seq[EventFilterBuilder] = { + val bus = new ReplayListenerBus() + + val builders = ServiceLoader.load(classOf[EventFilterBuilder], + Utils.getContextOrSparkClassLoader).asScala.toSeq + builders.foreach(bus.addListener) + + files.foreach { log => + Utils.tryWithResource(EventLogFileReader.openEventLog(log, fs)) { in => + bus.replay(in, log.getName) + } + } + + builders + } +} + +/** + * [[EventFilter]] decides whether the given event should be filtered in, or filtered out when + * compacting event log files. + * + * The meaning of return values of each filterXXX method are following: + * - Some(true): Filter in this event. + * - Some(false): Filter out this event. + * - None: Don't mind about this event. No problem even other filters decide to filter out. + * + * Please refer [[FilteredEventLogFileRewriter]] for more details on how the filter will be used. + */ +private[spark] trait EventFilter { Review comment: > The code in BasicEventFilter.filterStageSubmitted seems to be "return true if the given event references a stage that is part of a live job", but "filter" to me means "should I remove whatever parameter I'm passing to to this method", so they seem contradictory. I agree "filter" is interpreted as both opposite sides; when we say about "spam filter", it means "filter out", where we use `filter` in Scala it means "filter in". Here I use "filter" as "filter in" to be consistent with Scala, but I still agree the word brings confusion. > Java's predicate classes usually use accept which is clear in its intent. "accept" vs "reject" is much clearer. Thanks for the great suggestion! Will address. > Also, it might be cleaner to have this trait just have one method: > `def accept(event: SparkListenerEvent): Boolean` > Let the implementation match on the event type if needed Yeah that sounds OK - I thought we'd be better to provide methods for all available events so that implementations don't forget to deal with types of events, but anyway implementations should know which types of events they should care, so that should be OK. > It could even be a PartialFunction[SparkListenerEvent, Boolean] so you avoid the Option (no match = don't care). > (I see you use inheritance later in the SQL code; partial functions make that a little more interesting, but still doable.) I'm sorry I'm not clear about your suggestion. Do you suggest me to use `lift` to deal with Option in caller side, or do some composing? At least two partial functions (core side implementation and sql side implementation) can't be composed by `orElse` - it may work for "don't care" but we don't filter out event unless "ALL" filters reject it. We'll have to call the function individually like the patch is doing. If we just don't want to let implementations deal with Option and have simpler implementations, yes that can be handled in caller side. Let me try to deal with it. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
