SA-20902

Summary

File Listener on multiple nodes can lock a Work object.

User has two nodes in Production and the File Listener is active on both the nodes.

In the current functionality the File Listener activity picks up a file and locks the Work object in order to update it. When there are multiple files related to same work object in the folder, the first listener to process one of the files locks the work object, the second file listener picks up a file that updates the same work object and attempts to open it and at this point a locking error is thrown.

The File is still getting moved to Completed folder but the complete activity is not finished due to locking error.
 

Error Messages

User owns personalized exception message there is no correlating pega exception  in the logs.

2016-02-09 13:31:52,812 [fault (self-tuning)'] [  STANDARD] [                    ] [     PegaRULES:07.10] (ML.VDF_DE_OC_Work_Order.Action) ERROR File.UpdateMOMStatus|process|A894638982F37DFE1028D78AE8E0E0DF3|1455021111199000|DigitalOrderUtilities/VDF-FW-OCFW-Work-Order/ConnectMOM // - The Order O-17458 cannot be updated because this is locked

Steps to Reproduce

1. Create File listener.
2. Write logic to update work object in the listener service activity. The work object ID to be opened will be inside the file as one of the fields.
3. Enable listener in multiple nodes and feed files related to same work object.
4. One of the nodes will throw lock error and fail the processing however the file gets moved to completed folder.

Root Cause

User misunderstood the functionality of the listener, the files were correct and being processed correctly. They assumed that if their logic in the activity failed it also meant that the file processing had failed and expected the file listener to retry the file.

Resolution

The following information on how to achieve the retry of their logic is proposed to the user:

•  Include one listener hence everything is processed in a synchronous fashion and this lock issue will not exist.
• To modify the activity is to retry that is, when the object is locked user jumps to a ERR step and log a message, one can, at this point either code a wait or sleep and then jump back up to the obj-open and retry the code. One must take into consideration on how many times to try, before actually failing otherwise it could stay in an infinite retry loop.
• When you reach the ERR stage use a java step and throw an exception; this will force listener to rename the file being processed to .err  and move it to the completed folder or delete the file depending on how the listener is configured.

At this point one can do several things that you could have a cron job that picks up all the .err files and renames them back to their original extension.
And also place the files back into the source folder where they will be picked up and reprocessed.

Or one can configure another listener which listens for .err files and tries to process them using the same activity as your other listener.