Details
-
Bug
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
2.0.0
-
None
Description
Noticed the following on an upgraded cluster:
This is not related to EU it seems:
java.lang.NullPointerException
at org.apache.ambari.server.controller.internal.AlertResourceProvider.toResource(AlertResourceProvider.java:277)
at org.apache.ambari.server.controller.internal.AlertResourceProvider.getResources(AlertResourceProvider.java:234)
at org.apache.ambari.server.controller.internal.AlertResourceProvider.queryForResources(AlertResourceProvider.java:160)
at org.apache.ambari.server.controller.internal.ClusterControllerImpl$ExtendedResourceProviderWrapper.queryForResources(ClusterControllerImpl.java:966)
at org.apache.ambari.server.controller.internal.ClusterControllerImpl.getResources(ClusterControllerImpl.java:141)
at org.apache.ambari.server.api.query.QueryImpl.doQuery(QueryImpl.java:529)
at org.apache.ambari.server.api.query.QueryImpl.queryForResources(QueryImpl.java:398)
at org.apache.ambari.server.api.query.QueryImpl.execute(QueryImpl.java:222)
It looks like this is a problem with database consistency, namely that our upgrade logic does NOT properly enforce non-null and default values!
"Not good..."
//TODO workaround for default values, possibly we will have full support later if (columnInfo.getDefaultValue() != null) { columnInfo.setNullable(true); }
Turns out we're doing at least 2 things very wrong here when changing the DB on Ambari upgrade:
- Not enforcing non-NULL constraint on columns
- Not enforcing a default constraint on column
This is most likely due to limitations in EclipseLink's TableDefinition and FieldDefinition classes which we rely on for our upgrade logic.
Attachments
Attachments
Issue Links
- links to
