4 of 4 people found this helpful
I can only assume that there was some activity that touched these records. You can look at API/SQL/Filter logging, identify the INSERTS into ft_pending that match these schemaIDs/FieldIds and you should be able to track down what is modifying these records and causing them to be reindexed.
Could be an escalation, DSO, or just user activity. Could be a Push fields action updating a bunch of records in the form all at once.
With the number of records there, I would guess it might be an escalation.
This seems to be as-designed since in 8.1, any updates/creates/deletes to an FTIndexed field will cause an entry into ft_pending.
The good news, for many of us, is that this was one of the efficiencies added to 9.x FTS. We no longer allow the creation of the subsequent entries into ft_pending if the same form/field/operation is already being indexed. So when you are able to upgrade to 9.x+ this will no longer be a problem.
Until then, you may have to do one of the following: remove some of your FTS/MFS indexes, identify and modify escalations that are modifying FTindexed records so that they don't run faster than the indexer's ability to index them.
One thing I didn't really mention was whether indexing was keeping up. You may be seeing a lot of these still in ft_pending because the indexing is not keeping up with the amount of data in the ft_pending table. This is another reason to look at the INSERTs in ft_pending and find out what is adding all the work. You might be able to keep up if you could simply stop some of the huge dumps of records into ft_pending from, perhaps, escalations or filter push fields.
Thanks Douglas, You are right, I managed to find out that the reason, In my case being Service Request (REQ000000133784) (Parent) and Change request (CRQ000000041673) (Child), for some reason whenever a change request is cancelled, the cancellation entries keeps re-appearing in the Application Pending form and approval engine is processing the cancellation entries. Even though the Change request is in cancelled status, new entries are created in the application for cancellation. This in turn is touching the Service Request (REQ000000133784) (Parent) and Change request (CRQ000000041673) (Child) record, triggering the indexing (ft_pending table.
Not sure, why these cancellation entries are reappearing in the application pending form.
1 of 1 people found this helpful
Thank you very much Douglas. Managed to fix and It was due to an Incorrect workflow customization.