Learn about the known issues in Ranger, the impact or changes to the functionality, and
the workaround.
Known Issues in Cloudera Runtime 7.3.1.600 SP3 CHF1
There are no new known issues identified in this release.
Known Issues in Cloudera Runtime 7.3.1.500 SP3
There are no new known issues identified in this release.
Known Issues in Cloudera Runtime 7.3.1.400 SP2
There are no new known issues identified in this release.
Known Issues in Cloudera Runtime 7.3.1.300 SP1 CHF1
There are no new known issues identified in this release.
Known Issues in Cloudera Runtime 7.3.1.200 SP1
There are no new known issues identified in this release.
Known Issues identified in Cloudera Runtime 7.3.1.100 CHF 1
There are no new known issues identified in this release.
Known Issues in Cloudera Runtime 7.3.1
- OPSAPS-75673: Wrong enablement of Ranger RMS Database Full Sync command
- 7.1.8, 7.1.9, 7.1.9 SP1, 7.2.18, 7.3.1
- The Ranger RMS Database Full Sync command should be enabled
only when all RMS server instances are stopped. This is required to ensure that the
RMS database synchronizes correctly without introducing conflicts or data corruption.
However, when HA (High Availability) is enabled on the cluster, the command becomes
available from drop-down, even though only one Ranger RMS instance is stopped while
the others are still running.
- None.
- UnsupportedClassVersionError
- 7.1.9, 7.1.9 SP1, 7.3.1
- JDK 8 deployments support Nashorn JavaScript engine, which is built-in and fully
compatible, whereas JDK 17 deployments support GraalJS script engine due to
unavailability of Nashorn.
When your cluster supports both JDK 8 and JDK 17, then
while a Java application, running on JDK 8, uses generic interfaces like
ScriptEngine (from the javax.script package), the ScriptEngineManager class scans
the classpath for available script engine implementations through the service
provider mechanism, and detects the GraalJS as a provider for JavaScript, because in
this case the GraalJS library (version 22.3.0) is also included on the classpath.
The ScriptEngineManager then attempts to instantiate it, when requesting a "js" or
"javascript" engine, and triggers an UnsupportedClassVersionError.
- Remove the GraalJS library from the classpath.
- CDPD-3296: Audit files for Ranger plugin components do not
appear immediately in S3 after cluster creation
- 7.2.16, 7.2.17, 7.2.18, 7.3.1
- For Ranger plugin components (Atlas, Hive, HBase, etc.), audit
data is updated when the applicable audit file is rolled over. The default Ranger
audit rollover time is 24 hours, so audit data appears 24 hours after cluster
creation.
-
To see the audit logs in S3 before the default rollover time of 24 hours, use the
following steps to override the default value in the
Cloudera Manager safety valve for the applicable service.
- On the Configuration tab in the applicable service,
select Advanced under CATEGORY.
- Click the + icon for the <service_name> Advanced
Configuration Snippet (Safety Valve) for
ranger-<service_name>-audit.xml property.
- Enter the following property in the Name box:
xasecure.audit.destination.hdfs.file.rollover.sec.
- Enter the desired rollover interval (in seconds) in the
Value box. For example, if you specify
180, the audit log data is updated every 3 minutes.
- Click Save Changes and restart the service.
