Known Issues in Schema Registry
Learn about the known issues in Schema Registry, the impact or changes to the functionality, and the workaround.
- CDPD-40380: Authorization checking issue when Kerberos is disabled
Due to an issue in Ranger, when Kerberos is disabled then it is not possible to check authorization.
- Open SR config in Cloudera Manager.
- Find the "ranger.plugin.schema-registry.service.name" field.
- Replace GENERATED_RANGER_SERVICE_NAME with the actual name of the service.
- Restart Schema Registry.
- CDPD-49304: AvroConverter does not support composite default values
- AvroConverter cannot handle schemas containing a
STRUCTtype default value.
- OPSAPS-66356: Schema Registry's integration with Atlas does not work in secure clusters where Ranger authorization is enabled
- Due to an error in the default Ranger policies for Atlas, the
integration between Schema Registry and Atlas does not work. As a result, Schema Registry
related entities (metadata) are not created in Atlas. Viewing or monitoring schema entity
relationships is not possible. If this issue is present in your cluster, the following
exceptions will be present in the Schema Registry and Atlas server's log:
- Schema Registry server
ERROR com.cloudera.dim.atlas.bootstrap.AtlasModelBootstrap: Error while setting up the Schema Registry model in Atlas.
- Atlas Server
org.apache.atlas.exception.AtlasBaseException: schemaregistry is not authorized to perform create entity-def schema_metadata_info
- Schema Registry server log
- Access the Ranger Console (Ranger Admin web UI).
- Click the cm_atlas resource-based service.
- Add the
schemaregistryuser to the default policies.
All policies that require an update will at minimum already contain the
nifiusers. Adding the
schemaregistryuser to the
Allow users to manage favorite searchesdefault policy is not required.
- Restart the Schema Registry service.
Restarting the services triggers the creation of the missing entities in Atlas.
- CDPD-54379: KafkaJsonSerializer and KafkaJsonDeserializer do not allow null values
- KafkaJsonSerializer and KafkaJsonDeserializer do not allow the data to be null, resulting in a NullPointerException (NPE).
- CDPD-49217 and CDPD-50309: Schema Registry caches user group membership indefinitely
Schema Registry caches the Kerberos user and group information indefinitely and does not catch up on group membership changes.
- Restart Schema Registry after group membership changes.
- CDPD-56890: New schemas cannot be created following an upgrade
- If you delete the latest version of a schema (the one with the highest ID) from the Schema Registry database before an upgrade, you might not be able to create new schemas after you upgrade the cluster to a newer version.
- Access the Schema Registry database. Go to and search for "database" if you don't know the name, host, or port of the Schema Registry database.
- Cross reference the ID's in the
schemaVersionIdcolumn of the
schmema_version_statetable with the ID's found in the
- Delete all records from the
schema_version_statetable that contains a
schemaVersionIdnot present in the
- CDPD-58265: Schema Registry Client incorrectly applies SSL configuration
- The Cloudera distributed Schema Registry Java client might fail to apply the SSL configurations correctly with concurrent access in Jersey clients due to a Jersey issue related to JDK.
- Before using
HttpsURLConnectionin any form concurrently, call
javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory()once in the custom client application.
- OPSAPS-68139: Schema Registry does not apply cluster wide Kerberos principal mapping by default
- Schema Registry does not apply the cluster-wide Kerberos auth-to-local (ATL) rules from the Core Setting service.
- Manually set the Schema Registry Kerberos Name Rules property to match the configuration of the Core Setting service.
- OPSAPS-68171: Schema Registry does not set Knox principal and service user as trusted proxies when using custom Kerberos principals
- Schema Registry automatically sets the Knox principal name as a trusted proxy. If the Schema Registry Kerberos Name Rules property is set in deployments where custom Kerberos principals are used, Knox might not be allowed to work as a trusted proxy.
- Manually configure the Knox user name by adding the
following to Schema Registry Server Advanced Configuration Snippet (Safety
knox_principal_name=[***KNOX USER NAME***]
- CDPD-48822: AvroConverter ignores default values when converting from Avro to Connect schema
- AvroConverter does not propagate field default values when converting Avro schemas to Connect schemas.
- CDPD-55381: Schema Registry issues authentication cookie for the authorized user, not for the authenticated one
- When the authenticated user is different from the authorized user, which can happen when Schema Registry is used behind Knox, authorization issues can occur for subsequent requests as the authentication cookie in Schema Registry stores the authorized user.
- Access Schema Registry directly, without using Knox, if
possible. If not, ensure that the name of the end user that tries to connect does not
- OPSAPS-68138: Schema Registry and Kafka cannot download policies from Ranger when using custom Kerberos principals
- Ranger repositories created by the scripts that start Kafka, Kafka Connect and Schema Registry only add the principal name of related services to the repository users and the policies. In deployments where custom Kerberos principals are used, this can cause repository and policy download issues for Kafka, Kafka Connect and Schema Registry. Additionally, this can result in permission issues for related services.
- Manually set the repository users and the policy users to refer to the correct service user names.
- CDPD-60160: Schema Registry Atlas integration does not work with Oracle databases
Schema Registry is unable to create entities in Atlas if Schema Registry uses an Oracle database. The following will be present in the Schema Registry log if you are affected by this issue:
ERROR com.cloudera.dim.atlas.events.AtlasEventsProcessor: An error occurred while processing Atlas events. java.lang.IllegalArgumentException: Cannot invoke com.hortonworks.registries.schemaregistry.AtlasEventStorable.setType on bean class 'class com.hortonworks.registries.schemaregistry.AtlasEventStorable' - argument type mismatch - had objects of type "java.lang.Long" but expected signature "java.lang.Integer"
This issue causes the loss of audit data on Oracle environments.
- CDPD-48853: Schemas created with the Confluent Schema Registry API cannot be viewed in the UI
- Schemas created in Cloudera Schema Registry using the Confluent
Schema Registry API are not visible in the Cloudera Schema Registry UI.
In addition, the /api/v1/schemaregistry/search/schemas/aggregated endpoint of the Cloudera Schema Registry API does not return schemas created with the Confluent Schema Registry API.
A typical case where this issue can manifest is when you are using the Confluent Avro converter for SerDes in a Kafka Connect connector and the connector connects to Cloudera Schema Registry. That is, the
value.converterproperties of the connector are set to io.confluent.connect.avro.AvroConverter, and
value.converter.schema.registry.urlare set to a Cloudera Schema Registry server URL.