Description

Issue

When starting a discovery of a service map, discovery stops immediately and the java.lang.NullPointerException error can be seen in the log.

NullPointerException

Troubleshooting

The NullPointerException error is thrown during recomputation of the business service. The most common reason for this error during recomputation is an existing duplicate dependencies in cmdb_rel_ci table. Having an NPE (NullPointerException) in such cases is not desirable; however, the recomputation logic behavior was completely updated in Kingston and such errors are not likely to happen in Kingston and newer releases.

To find the root cause for the issue you need to (short term):

Find the CI that the recomputation was processing when the error happened
Look for duplicate relationships for the device and remove them

For a long-term solution, you need to determine what caused the duplicate relationships.

Finding the CI

To find the CI, navigate to System Definition > Scripts - Background and run the following script. The output will be logged to the screen.

Note – Replace empty in gr.get('empty') with the sys_id for the business service.

gs.setProperty("glide.cmdb.logger.source.service_mapping.coordinator","info,warn,error,*"); 
gs.setProperty("glide.cmdb.logger.source.service_mapping.template", "info,warn,error,*"); 
gs.setProperty("glide.cmdb.logger.source.service_mapping.matching", "info,warn,error,*"); 
gs.setProperty('glide.transaction.max_logs', 200*10000); 

var gr = new GlideRecord('cmdb_ci_service_discovered'); 
gr.get('empty'); // <This line must be updated with service sys_id
var layerId= gr.layer; 
var layerGr= new GlideRecord('svc_layer'); 
layerGr.get(layerId); 
var env= sn_svcmod.ServiceContainerFactory.loadEnvironment(layerGr.environment); 

var allLayers= env.layers(); 
for (var i= 0 ; i< allLayers.length; i++) { 
var layer = allLayers[i]; 
layer.markRecomputationNeeded(); 
} 

SNC.ServiceMappingFactory.recomputeLayer(layerGr); 
gs.setProperty('glide.transaction.max_logs', 200*1000); 
gs.setProperty("glide.cmdb.logger.source.service_mapping.coordinator","info,warn,error"); 
gs.setProperty("glide.cmdb.logger.source.service_mapping.template", "info,warn,error"); 
gs.setProperty("glide.cmdb.logger.source.service_mapping.matching", "info,warn,error");

The CI with the duplicate relationship should be the last CI seen in the output before the NPE error. In the following example output snippet, the CI would be 567bcdb49179390020e5db5405e32514.

service_mapping.template :>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>## UPDATE: convertRecordIntoElements: (CI:cmdb_ci_win_server:9667 # 567bcdb49179390020e5db5405e32514) => (cmdb_ci_win_server:9668) 
service_mapping.coordinator : Attempting to process layer Template on environment bb5e3069dbbb4304fc1cf9961d9619bb resulted in an exception:: no thrown error 
service_mapping.coordinator : >> java.lang.NullPointerException: no thrown error 
service_mapping.coordinator : : no thrown error

In this example, it was found that the CI had multiple "hosted on:hosts" relationship records to the same CI. For different CI records, there will be different relationship types that might cause the error. Once the CI is found, relationships in the cmdb_rel_ci table can be filtered for "parent = CI or child = CI", CI found in script output, to look for duplicate relationships.

Identification rules

Very often such duplicate relationship/CI(s) are created due to identification rules that should be dependent but are set to independent. To look for such identification rules, navigate to System Definition > Scripts - Background and run the following script to find identifiers that are set to independent and should not be.

var gr = new GlideRecord('cmdb_identifier'); 
gr.addQuery('independent', 1); 
gr.query(); 
while (gr.next()) { 
if (GlideDBObjectManager.get().isInstanceOf(gr.applies_to, 'cmdb_ci_appl') || 
GlideDBObjectManager.get().isInstanceOf(gr.applies_to, 'cmdb_ci_lb_service')) { 
gs.print("Application " + gr.applies_to + " has an independent identifier rule"); 
} 
}

Once these steps are followed (duplicate relationships are found and removed), the business service map discovery can be run again without the NPE error.

Background scripts, to search for duplicate application and cluster relationships

// find an application that runs on more than one host (wrong identifier). 
var gr = new GlideAggregate('cmdb_rel_ci'); 
gr.addQuery('type', '60bc4e22c0a8010e01f074cbe6bd73c3'); // runs on relation 
gr.addQuery('child.sys_class_name','INSTANCEOF','cmdb_ci_server' ); 
gr.addQuery('parent.sys_class_name','INSTANCEOF','cmdb_ci_appl' ); 
gr.addAggregate('COUNT'); gr.groupBy('parent'); gr.query(); 
gs.print('*** Affected Applicataions: ***'); 
while (gr.next()) {         
if (gr.getAggregate('COUNT') > 1) {         
gs.print(gr.parent + ":" + gr.parent.name);     
} 
}   

// find servers that are hosted on more then one cluster node  
var gr = new GlideAggregate('cmdb_rel_ci'); 
gr.addQuery('type', '5f985e0ec0a8010e00a9714f2a172815'); 
gr.addQuery('child.sys_class_name', 'cmdb_ci_win_server'); 
gr.addQuery('parent.sys_class_name', 'cmdb_ci_win_cluster_node'); 
gr.addAggregate('COUNT'); 
gr.groupBy('child'); 
gr.query(); 
gs.print('*** Affected Servers: ***'); 
while (gr.next()) {    
if (gr.getAggregate('COUNT') > 1) {         
gs.print(gr.child + ":" + gr.child.name);     
} 
}

Notifications