vanzin commented on a change in pull request #23156: [SPARK-24063][SS] Add
maximum epoch queue threshold for ContinuousExecution
URL: https://github.com/apache/spark/pull/23156#discussion_r259953213
##########
File path:
sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala
##########
@@ -1413,6 +1413,14 @@ object SQLConf {
.booleanConf
.createWithDefault(true)
+ val CONTINUOUS_STREAMING_EPOCH_BACKLOG_QUEUE_SIZE =
+ buildConf("spark.sql.streaming.continuous.epochBacklogQueueSize")
+ .internal()
+ .doc("The max number of entries to be stored in queue to wait for late
epochs. " +
+ "If this parameter is exceeded by the size of the queue, stream will
stop with an error.")
+ .intConf
+ .createWithDefault(10000)
Review comment:
> Having a pre-defined number I still think it has a value to notify users
about a possibly faulty query
That still doesn't explain why is it OK to potentially break things that
were working fine.
Do you have statistics that show that this queue almost never gets close to
this threshold, unless the application is for some reason unhealthy?
I understand that the previous behavior when things fail is bad. But it's
worse to just break stuff that is not broken.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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]
