[
https://issues.apache.org/jira/browse/SPARK-19013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15795018#comment-15795018
]
Steve Loughran commented on SPARK-19013:
----------------------------------------
Re-opening this as it may deserve a bit of a closer look. FWIW, I don't think
it's a negative cache so much as an eventual consistency on any created lock
file: if a file is being used as a "log in use" marker, then even after the
file is deleted it may be briefly visible to others.
This is the kind of problem which HADOOP-13345 is going to deal with. Looking
at the codepath for {{HDFSMetadataLog}}; there's still the issue of a reliance
on an atomic O(1) {{rename()}} for committing the work; neither requirement is
met on S3; Azure has the atomicity but its still potentially doing a copy.
> java.util.ConcurrentModificationException when using s3 path as
> checkpointLocation
> -----------------------------------------------------------------------------------
>
> Key: SPARK-19013
> URL: https://issues.apache.org/jira/browse/SPARK-19013
> Project: Spark
> Issue Type: Bug
> Components: Structured Streaming
> Affects Versions: 2.0.2
> Reporter: Tim Chan
>
> I have a structured stream job running on EMR. The job will fail due to this
> {code}
> Multiple HDFSMetadataLog are using s3://mybucket/myapp
> org.apache.spark.sql.execution.streaming.HDFSMetadataLog.org$apache$spark$sql$execution$streaming$HDFSMetadataLog$$writeBatch(HDFSMetadataLog.scala:162)
> {code}
> There is only one instance of this stream job running.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
