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.
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?).
Posted: 6 years ago
Updated: 6 years ago
Posted: 19 Nov 2015 12:07 EST Updated: 19 Nov 2015 12:08 EST
Tobias Bruendler (bruet)
Software Solutions Engineer
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.