[
https://issues.apache.org/jira/browse/YARN-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18049902#comment-18049902
]
ASF GitHub Bot commented on YARN-11916:
---------------------------------------
cnauroth commented on code in PR #8164:
URL: https://github.com/apache/hadoop/pull/8164#discussion_r2662394891
##########
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice/src/test/java/org/apache/hadoop/yarn/server/timelineservice/storage/FileSystemTimelineWriterImpl.java:
##########
@@ -51,7 +52,27 @@
* This implements a FileSystem based backend for storing application timeline
* information. This implementation may not provide a complete implementation
of
* all the necessary features. This implementation is provided solely for basic
- * testing purposes, and should not be used in a non-test situation.
+ * testing purposes, and MUST NOT be used in a non-test situation.
+ * <p>
+ * Key limitations are:
+ * <ol>
+ * <li>Inadequate scalability and concurrency for production use</li>
+ * <li>Weak security: any authenticated caller can add events to any
application
+ * timeline.</li>
+ * </ol>
+ * <p>
+ * To implement an atomic append it reads all the data in the original file,
+ * writes that to a temporary file, appends the new
+ * data there and renames that temporary file to the original path.
+ * This is makes the update operation slower and slower the longer an
application runs.
Review Comment:
Nitpick: remove the word "is."
> FileSystemTimelineReaderImpl vulnerable to race conditions
> ----------------------------------------------------------
>
> Key: YARN-11916
> URL: https://issues.apache.org/jira/browse/YARN-11916
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: timelineserver
> Affects Versions: 3.4.2
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Minor
> Labels: pull-request-available
>
> Yarn timelineserver FileSystemTimelineReaderImpl implementation does atomic
> updates via: copy, append, rename. This gives it bad scalability and
> concurrent calls will lose data.
> has bad concurrency on write and will lose updates. And its scalability
> Not plans to fix what was just the PoC of the v2 API, just
> * update javadocs
> * warn on startup that people should stop it.
> * do some other hardening while there, and test cleanup
> This code is @Private/@Unstable. Maybe we can move it into the -test jar.
> Nobody will complain.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
