Incorrect Number of Errors are Reported by Pin_deferred_act (Doc ID 2721922.1)

Last updated on FEBRUARY 05, 2024

Applies to:

Symptoms

ACTUAL BEHAVIOR
------------------
The multi-threaded application (MTA) pin_deferred_act reports incorrect number of errors on the console. That is, when the deferred opcode is finishing with any error, there is no impact on the MTA report produced by pin_deferred_act, and therefore user cannot recognize if there were errors or not.

SCENARIO 1:
------------------

1. Create account ( pin_virtual_time (pvt)  2018-10-31T10:00:00 )
2. Create service ( pvt   2018-10-31T10:15:00 with effective time 30.11.2018. The effective is in the future, so setting alias operation is scheduled in table schedule_t)
3. Make a manual update on schedule_t to BUF with flist to purposely damage it (by faking its poid for example, this is just to simulate the issue)
4. Change pvt to 30.12.2018 and run pin_deferred_act application
5. See below report from MTA on the console:
   
   
   
   
6. See that MTA reported no error, but inside Connection Manager (CM) logs there is error on opcode execution.

SCENARIO 2:
------------------

Note: A solution (patch) was applied for the scenario 1, however two new issues were uncovered as below:

Case 1:

Configuration:

Below parameters are set in pin.conf file in the folder where pin_deferred_act is executed:
- pin_mta respawn_threads 0
- pin_mta max_errs 1

Steps:

1. Create account ( pvt 2018-10-31T10:00:00 )
2. Create service ( pvt 2018-10-31T10:15:00 with effective time 30.11.2018. The effective is in the future ,so setting alias operation is scheduled in table schedule_t
3. Make manual update on schedule_t to BUF with flist to purposely damage it (by faking its poid)
4. Change pvt to 30.12.2018
5. Run pin_deferred_act application
6. Application reports incorrect number of errors:
   
   Total number of records processed = 1.
   Number of data errors encountered = 2.
   Total number of errors encountered = 2.
   
   but expected is:
   
   Total number of records processed = 1.
   Number of data errors encountered = 1.
   Total number of errors encountered = 1.
   
   
7. Application report incorrect exitCode, expected 1 but returns 0

Case 2:

Configuration:

Below parameters are set in pin.conf file in the folder where pin_deferred_act is executed:
- pin_mta respawn_threads 0
- pin_mta max_errs 2

Steps:

1. Create 4 accounts, that is, repeat steps 1 to 4 from previous case
2. Run pin_deferred_act application, see console output below:
   
   > pin_deferred_act -verbose
   Thread (37026672) begins ...
   Thread (26536816) begins ...
   Thread (58006384) begins ...
   Thread (76647280) begins ...
   Thread (47516528) begins ...
           Fetched units per step: (4)
   Total Fetched (4) units, err 0
   Fetched (4) units in Total.
   Thread (76647280) exits ...
   Thread (47516528) exits ...
   Thread (58006384) exits ...
   Thread (37026672) exits ...
   Thread (26536816) exits ...
   Total number of records processed = 4.
   Number of data errors encountered = 5.
   Total number of errors encountered = 5.
   
   
3. See application return code:
   
   > echo $?
   70
   
   
4. Expected: application reports correct number of errors as shown below:
   
   Total number of records processed = 4.
   Number of data errors encountered = 4.
   Total number of errors encountered = 4.
   
   
5. Expected: application reports correct exitCode as shown below (when number of errors >= value of pin_mta max_errs):
   
   >echo $?
   1

EXPECTED BEHAVIOR
------------------
Overall expectation in above scenarios is that, when there is an error from the deferred opcode execution, the pin_deferred_act application should show on the console that there were errors and the correct number of errors must be reported.

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.