Agent processing same entry multiple times in one run with MaxAttempts>1 - 7.1.7
For MaxAttempts greater than 1, Agent is processing the same entry multiple times in one run.
We have MaxAttempts set to 3 is that Agent is processing the entry 3 times in one run,
But the expectation here is that it should attempt to process the entry only once in one run and it fails then the second time when the agent wakes up should process the same entry and again if it fails then in the third run it should process the entry,
Otherwise it doesn´t make sense if it attempts to process the same entry 3 times in one run (It will always be failed).
Regarding the MinimumAgeForProcessing parameter - We tried to put some value in that as well but what it is doing is delaying only the first time processing but we want to delay the consecutive attempts of agents.
PRPC 7.1.7
How can we achieve this behaviour?
Pegasystems Inc.
US
Tobias,
Hello. Are you sure the same agent is processing the item? My expectation is that it should leave it until the next time is sleeps/wakes up. That said, if you have the same agent running on many nodes, I don't believe the other nodes skip it, so it's possible that a number of them may try to process the item in a very short period of time if there are many nodes all pulling from the same queue. As for your last question, are you saying you want to build into your goal time activity some error trapping that will reset the goal time if you run into a specific error condition? There are out of the box activities to do stuff like that. I don't recall what they are off the top of my head (ResetSLA maybe?).
Thanks,
Mike
Updated: 19 Nov 2015 12:08 EST
EPAM Systems
CH
Hello Mike,
Thanks for your comment. I have the same expectation that it should leave it until the next time it seeps/wakes up. The Agent is running only on one node.
How would one force the item to leave the queue instead of retrying again?
Pegasystems Inc.
US
Tobias,
There are certain types of errors that result in the item going to the broken queue. I'm not sure if that's exactly what you are looking for. Depending on how you build your activity, if you can capture the error in an activity, you could do a subsequent queue-for-agent that would put it into the queue at a later date/time of your choosing. From the perspective of the current run, the activity would need to appear to be successful so that the item doesn't get requeued. Obviously, this doesn't help if the failure is the engine trying to grab a lock on your work object or something, so this strategy won't work for all things, but might be something to consider.
Regards,
Mike