this is happening here and flooding application pending, what is the implication to the end user? what will stop working in the system because of this? is there any workaround for now? ...when I turn on a filter log on the server all i'm getting is a flood of get entries on these broken entries so it's a nightmare.
What actually adds these records to the pending queue? Is it an API?
Seems like it would be an easy fix if it is workflow.
This has been an issue from time to time (but not ALL the time) for our new 9.1 environment (fortunately not yet in PROD). So we are keen to see the hot fix too!
IS there any high level description around that describes the work the CMDB Dispatcher does?? Especially the way it uses the App Pending form?? This comes up quite frequently (seeing lots of entries in this form from various sources, with no clear description of what they are doing, and hence whether it's ok to delete them or not if they seem 'stuck' etc.
Hi Daniel Hudsky, the entries are added mainly by the engine itself for server group purposes.
SyncUI also add records here as well as the old CMDB Console (for any kind of class/attributre modification). RE also add records for server group functionality purposes.
The problem seemed to have occurred with the migration to the new JCMDB engine.
Carey Walker, the CMDB Dispatcher is basically tasked with reading these pending records and notifying the appropriate process/engine to go and pick them up. Some processes directly read the form without expecting the Dispatcher to actually tell them to.
Normally is quite ok to delete aging records since there should be nothing aging in this form. Records should remain here temporarily and not for long since the appropriate process should pick it up farily quickly, so anything that has been here for more than 1 hour is a candidate for removal. If you have more than 1 record from the same process then you need to investigate why. Note that only a small percentage of this form is CMDB records... most record I've seen are actually ITSM processes.
If Application pending form is flooded with more entries like ~100K etc. it may impact the plugin performance which may dependent on AR dispatcher to dispatch any request coming through Application pending form.
If you come across this situation and the fix is not available, make sure the outdated entries are being cleaned up regularly.
Hi Manish, have you managed to develop the hot fix for this issue?
2 of 2 people found this helpful
if I understand Manish correctly, then the fix would be to find all filters where the call is made. As he shows in the example:
Application-Command Dispatch Register-Category -s"AR System CMDB Dispatcher" -tCMDB Dispatcher -o"araps_cmdb.lck" -l"22:<server name>:Global\c:*program files*bmc software*arsystem*confRemedyCMDBEngSigEvent"
Application-Command Dispatch Register-Category -s"AR System CMDB Dispatcher" -t "CMDB Dispatcher" -o"araps_cmdb.lck" -l "22:<server name>:Global\c:*program files*bmc software*arsystem*confRemedyCMDBEngSigEvent"
and add double quotes around the value for argument -t. Although I can't say that it is clear to me how to find these filters or if is a filter at all that. The syntax looks like an AR filter action "Application-Command Dispatch Register-Category". This detail is the missing link for me anyway.
Is this the official fix?
Is it fixed in Atrium Core 18.05?