spark-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <>
Subject [jira] [Commented] (SPARK-19013) java.util.ConcurrentModificationException when using s3 path as checkpointLocation
Date Tue, 03 Jan 2017 13:01:58 GMT


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

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:
>             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$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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message