[
https://issues.apache.org/jira/browse/HADOOP-17597?focusedWorklogId=587432&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-587432
]
ASF GitHub Bot logged work on HADOOP-17597:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 22/Apr/21 18:47
Start Date: 22/Apr/21 18:47
Worklog Time Spent: 10m
Work Description: steveloughran commented on a change in pull request
#2801:
URL: https://github.com/apache/hadoop/pull/2801#discussion_r618655930
##########
File path:
hadoop-tools/hadoop-aws/src/site/markdown/tools/hadoop-aws/troubleshooting_s3a.md
##########
@@ -1036,6 +1036,39 @@
This includes resilient logging, HBase-style journaling
and the like. The standard strategy here is to save to HDFS and then copy to
S3.
+### <a name="syncable"></a> `UnsupportedOperationException` "S3A streams are
not Syncable. See HADOOP-17597."
+
+The application has tried to call either the `Syncable.hsync()` or
`Syncable.hflush()`
+methods on an S3A output stream. This has been rejected because the
+connector isn't saving any data at all. The `Syncable` API, especially the
+`hsync()` call, are critical for applications such as HBase to safely
+persist data.
+
+The S3A connector throws an `UnsupportedOperationException` when these API
calls
+are made, because the guarantees absolutely cannot be met: nothing is being
flushed
+or saved.
+
+* Applications which intend to invoke the Syncable APIs call
`hasCapability("hsync")` on
+ the stream to see if they are supported.
+* Or catch and downgrade `UnsupportedOperationException`.
+
+These recommendations _apply to all filesystems_.
+
+To downgrade the S3A connector to simplying warning of the use of
Review comment:
fixed
--
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]
Issue Time Tracking
-------------------
Worklog Id: (was: 587432)
Time Spent: 1h 20m (was: 1h 10m)
> Add option to downgrade S3A rejection of Syncable to warning
> ------------------------------------------------------------
>
> Key: HADOOP-17597
> URL: https://issues.apache.org/jira/browse/HADOOP-17597
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 3.3.1
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The Hadoop Filesystem Syncable API is intended to meet the requirements laid
> out in [StoneBraker81] _Operating System Support for Database Management_
> bq. The service required from an OS buffer manager is a selectedforce out
> which would push the intentions list and the commit flag to disk in the
> proper order. Such a service is not present in any buffer manager known to us.
> It's an expensive operation -so expensive that {{Syncable.hsync()}} isn't
> even called on {{DFSOutputStream.close()}}. I
> Even though S3A does not manifest any data until close() is called,
> applications coming from HDFS may call Syncable methods and expect to them to
> persist data with the durability guarantees offered by HDFS.
> Since the output stream hardening of HADOOP-13327, S3A throws
> UnsupportedOperationException to indicate that the synchronization semantics
> of Syncable absolutely cannot be met.
> As a result, applications which have been calling the Syncable APIs are
> finding the call failing. In the absence of exception handling to recognise
> that the durability semantics are being met, they fail.
> If the user and the application actually expects data to be persisted, this
> is the correct behaviour. The data cannot be persisted this way.
> If, however, they were calling this on HDFS more as a {{flush()}} than the
> full and expensive DBMS-class persistence call, then this failure is
> unwelcome. The applications really needs to catch the
> UnsupportedOperationException raised by S3A _or any other FS strictly
> reporting failures_, report the problem and perform some other means of safe
> data storage
> Even better, they can use hasPathCapability on the FS or hasCapability() on
> the stream to probe before even opening a file or trying to sync it. the
> hasCapability() on a stream was actually implemented in Hadooop-2.x precisely
> to allow applications to identify when a stream could not meet the guarantees
> (e.g some of the encrypted streams, file:// before HADOOP-13...)
> Until they can correct their code, I propose adding the option for s3a to
> downgrade
> fs.s3a.downgrade.syncable.exceptions
> This will
> * Log once per process at WARN
> * downgrade the calls to noop()
> * increment counters in S3A stats and IO stats of invocations of the Syncable
> methods. This will allow for stats gathering to let us identify which
> applications need fixing in cloud deployments
> Testing: copy the hsync tests but expect exceptions to be swallowed and stats
> to be collected
> Also: UnsupportedException text will link to this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
