3

I have developed a Notes agent that cross matches documents in the database based on certain criteria. We have a development server, a train server and a live server and each is running an instance of the relevant application. The agent does exactly what we require on all three instances when we run the agent manually. The agent also runs fine when scheduled for a specific time on the development and train servers. However, when we schedule the agent on the Live server it does not run and the logs only state the following;

"Agent Manager: Execution time limit exceeded by Agent 'MatchingAlert|MatchingAlert' in database 'PBT\PBTLive.nsf'. Agent signer 'Application Development/IT/***************'"

All three servers appear to be set up exactly the same. Also, I have transfrred the documents from the Live to the Development instance and it still runs as scheduled on the Development instance so it can't be the fact that it is dealing with more documents in the Live instance. So what will be causing this?

Edit: Something just occurred worth mentioning. We wanted the Train instance to have exactly the same documents as the Live instance so I actually deleted the Train instance and made a new copy of it using the Live instance as a template and now the scheduled agent is not running and showing the same output to the logs as the Live instance so it must be to do with the Live instance and not the Live server but what would it be?

AJF
  • 1,801
  • 4
  • 27
  • 54
  • The answers so far are correct - your agent is timing out. Your task is to figure out what is taking so much time. What does the agent do? Does it call NotesDatabase.search()? Does it access documents via views? Do any of the views have date/time dependencies in their formulas? – Richard Schwartz Jun 25 '15 at 14:34

2 Answers2

1

According to log entry, the agent runs but needs to long to accomplish the task.

Maybe

  • "Max. LotusScript/Java execution time" in Server document is too short or
  • you don't have enough rights as 'Application Development/IT/***************'" signer on production server and the agent wastes time to try to access something again and again.

Make sure that agent's signer has all rights necessary to execute the agent.

Knut Herrmann
  • 30,880
  • 4
  • 31
  • 67
  • Thanks for your response. Our infrastructure team say the Max time is the same on all three servers and the schedule runs when all the Live documents are placed in the development instance - granted there is more going on in the Live server though - but our infrastructure people insist this is not the problem. Also, I have edited my question as something of some relevance has occurred – AJF Jun 25 '15 at 11:07
  • Does it work if you sign the agent and all other design elements with the server-id or administrator-id? – Knut Herrmann Jun 25 '15 at 11:09
  • @KnutHermann Inserted statements to dubug. The agent processes three views. The first two views appear to run fine as the debug message at the end of each of these two views being processed is output. The third view runs through an outer loop and an inner loop cross checking the documents on certain criteria. This third view starts processing because the debug at start is output but then the time out occurs. Think we can rule out the signing and permissions so will look at getting the "Max" increased for the Live server. The agent does not use NotesDatabase.search() or ftsearch() calls – AJF Jun 26 '15 at 11:04
  • 1
    Make sure that third view has no @Now or @Today in Selection formula and use `view.AutoUpdate = False` working with view. – Knut Herrmann Jun 26 '15 at 11:33
  • No I don't use "Now" or "today" in any of the view selection formulas and in fact the third view is simply based on fields. Also in the agent code I don't use getnthDocument I use getFirstdocument before the start of the loop and getNextDocument at the end of each loop. I will look into "view.AutoUpdate = False" though. Does this parameter stop the view being amended during the agent interrogating it? – AJF Jun 26 '15 at 13:26
  • Yes, it kind of "freezes" the view for the agent. – Knut Herrmann Jun 26 '15 at 15:30
  • I set this in all three views, the thrid view is now as follows; Set viewAllContracts = db.GetView("Contracts \ All By Year") viewAllContracts.Autoupdate = False but the outcome was the same. I then tried the Autoupdate = False on theViews in the development instance and now it fails with a timeout too. I removed the Autoupdate = False from all the views in the development instance and it worked fine again including getting to the last debug output at the end of the agent – AJF Jun 26 '15 at 15:43
1

The log entry quite clearly states what is wrong: The agents runs longer than it is allowed to run. Best practice is to add some logging to your agent.

First of all I would check, how long the agent runs in your test- environment (right- click on the agent after a successfull run and check the log).

If that time is just fast enough to complete within timelimit (e.g. 12 Minutes run and server is configured to allow maximum of 15 Minutes), then it might be enough to run the agent on a server with heavier load to exceed the time limit.

In addition: Usually there are two different settings for the maximum agent runtime, "Daytime Parameters" and "Nighttime Parameters". If one agent runs during nighttime, it has usually a lot more allowed runtime than during daytime.

Depending on the code you use, there can be several reasons why an agent runs much longer on one instance of a database as on an other (even on the same server).

e.g:

  • If you run through a view the view might not be up to date and has to be built first. This can take a huge amount of time on a heavily used server
  • connecting to another database might once be considered a "local" call and on another server it is a "remote"- call. Again this can have huge impact
  • because of different addressbooks in one case the signer of the agent might see only few documents, in the other case sees all of them
  • using any FTSearch- Method without an existing fulltext ...
  • Using NotesDocumentCollection.getNthDocument() can result in HUGE performance- issues ...

This all is guessing without knowing your code. And the reason for your problem most probably depends on your code.

So again the advice: Build in some "logging" in your code: Let it "tell" you, where it is, and what it has done already. Let it output runtimes... Then you will see, where your productive environment loses the time.

Tode
  • 11,795
  • 18
  • 34
  • 1
    Specifically, I would recommend adding in some logging immediately before and after opening any database, accessing any view, doing any NotesDatabase.search() or ftsearch() calls. Print statements in LotusScript or System.out.println in Java are sufficient for this purpose), but remember to comment them out after you've solved the problem. – Richard Schwartz Jun 25 '15 at 14:32
  • Inserted statements to dubug. The agent processes three views. The first two views appear to run fine as the debug message at the end of each of these two views being processed is output. The third view runs through an outer loop and an inner loop cross checking the documents on certain criteria. This third view starts processing because the debug at start is output but then the time out occurs. Think we can rule out the signing and permissions so will look at getting the "Max" increased for the Live server. The agent does not use NotesDatabase.search() or ftsearch() calls – AJF Jun 26 '15 at 11:04
  • So it is the first point in my list. But you don't use [NotesDocumentCollection.getNthDocument()](http://www-01.ibm.com/support/docview.wss?uid=swg21099588) do you? – Tode Jun 26 '15 at 12:43
  • @TorstenLink No I don't use "Now" or "today" in any of the view selection formulas and in fact the third view is simply based on fields. Also in the agent code I don't use getnthDocument I use getFirstdocument before the start of the loop and getNextDocument at the end of each loop. Your first point on your previous list - will avoiding this make the agent code more efficient then I assume? Is this the same as Knuts suggestion of using "view.AutoUpdate = False" – AJF Jun 26 '15 at 13:27
  • If you manipulate the documents in your agent, then you HAVE TO use AutoUpdate = False, otherwise the view will update after every single document change, and you might get errors like "entry not in view"... – Tode Jun 26 '15 at 13:35
  • @TorstenLink I set this in all three views, the thrid view is now as follows; Set viewAllContracts = db.GetView("Contracts \ All By Year") viewAllContracts.Autoupdate = False but the outcome was the same. I then tried the Autoupdate = False on theViews in the development instance and now it fails with a timeout too. I removed the Autoupdate = False from all the views in the development instance and it worked fine again including getting to the last debug output at the end of the agent – AJF Jun 26 '15 at 15:43
  • If you want assistance in performance tuning, then open a new thread with the code. I think THIS question is solved here – Tode Jun 26 '15 at 16:17