-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 7.0.0
-
Labels:
-
Environment:IDM master runs on a centOS 7 machine. MySQL as repo
When run clustered recon test, noticed the recon status report gives wrong info, it's either recon or the report behaves incorrectly. Here is an instance to run two nodes clustered recon from DJ to idm with 500 users, when create finishes, the report showed:
Recon state = {'_id': '62b15075-332e-40b5-adc1-4b9670de25a8-155', 'mapping': 'systemLdapAccounts_managedUser', 'state': 'ACTIVE', 'stage': 'ACTIVE_RECONCILING_TARGET', 'stageDescription': 'reconciling target entries', 'progress': {'source': {'existing': {'processed': 526, 'total': '500'}}, 'target': {'existing': {'processed': 26, 'total': '500'}, 'created': 500}, 'links': {'existing': {'processed': 26, 'total': '?'}, 'created': 500}}, 'situationSummary': {'SOURCE_IGNORED': 0, 'FOUND_ALREADY_LINKED': 0, 'UNQUALIFIED': 0, 'ABSENT': 500, 'TARGET_IGNORED': 0, 'MISSING': 0, 'ALL_GONE': 0, 'UNASSIGNED': 0, 'AMBIGUOUS': 0, 'CONFIRMED': 26, 'LINK_ONLY': 0, 'SOURCE_MISSING': 0, 'FOUND': 0}, 'statusSummary': {'SUCCESS': 526, 'FAILURE': 0},
Where I expect only 500 users are created and no CONFIRMED.
To reproduce with Pyforge:
1. Update config/config.cfg
[Stress] num_users = 10 duration = 50 ... [OpenIDM] host_name = ${Default:host_name} java_home = ${Default:java_home} java_args = ${Default:java_args} version = 7.0.0-SNAPSHOT previous_version = 6.5.0 protocol = http repo_type = mysql use_docker_repo = False jvm_debug_options = ${Default:jvm_debug_options} cloud = ${Default:cloud} recon_page_size = 100
2. Run the test as
run-pybot.py -c stress -s idm.clustered_recon.ReconLDAPToManUserInCluster OpenIDM
3. Check results/latest/debug.txt to see the recon progress flow and status report, or get recon report during the recon run and observe the symptom.
Note: The same problem doesn't occur for regular recon.
- relates to
-
OPENIDM-13740 Explicit repo table: validate mapping before CREATE
-
- Closed
-