1
votes

I would like to timeout a LotusScript agent internally. The Agent Manager has a timeout of 60 min with one task, which is needed for some agents. In my case the agent normally runs 7 - 10 min, but it might hang on opening a mail calendar profile. It just hangs, does nothing but consuming CPU and blocking other agents from running.

Is there any way to stop/interrupt the agent internally, so that I can set a timeout of 30 sec for that operation and if it does not succeed stop the agent?

Problematic Code Snippet:

Set notesDocument = notesDatabase.GetProfileDocument("calendarprofile")

Error on the Mail Server short time after the problem (other server than the agent server)

SchedMgr: Error processing calendar profile document (NoteID: NT00000902) in database XXXX/XXXX.nsf: Document has been deleted
2

2 Answers

2
votes

Understanding internally as without external agent, process and so on.

  1. If no operation is blocking, you can instanciate timer, check periodically if your time is comsumed and end graccefullly your code.
  2. If your code is blocked (as in your example) on an operation, there is nothing you can do: no preampt task, no interruption.

I had the same issue when using ole to write in Excel. When a dialogue box were openend in Excel the task (run by http) just stoped forever. The max time execution even don't work.

2
votes

As per @Emmanuel's answer, I don't believe you can do anything to set a timeout on the operation that is hanging. However, since you know about the problem you might be able to work around it using the NotesNoteCollection class. I.e., something like this:

dim c as NotesNoteCollection
set c = db.CreateNoteCollection(false)
c.selectProfiles = true
c.BuildCollection

Then you loop through the collection using id=c.getFirstNoteId and id=c.getNextNoteId(id) in a pattern similar to what you use to loop through a regular NotesDocumentCollection, retrieving each profile document using doc =db.GetDocumentByID(id) and checking with doc.isValid to make sure it's not a deletion stub (which seems to be the root of your problem), and then checking if it is the calendarprofile by calling doc.getItemValue("$Name") and examining the value in the 0th element of the value array. It's a string containing a prefix "$profile" followed by an underscore, a number (three digits, always?), and then the profile doc name and another underscore. (In some profile docs, $Name would also contain a username, which IIRC occurs after the second underscore, but that's not the case with the calendarprofile doc. Use NotesPeek to examine a mail database to see the format.) Then, once you've verified that the document exists and is not a stub, go ahead and use db.getProfileDocument to assure that you're working on the cached version of the note.

You might also want to investigate why your code is hanging. I've not run into a situation like this before, but I'm wondering if there might be an excessive number of deletion stubs in the database and your code is triggering some sort of cleanup operation on them that is taking a very long time. That's just a guess, but this behavior isn't normal and even though I believe you can work around it, that might not be true. It's just a guess. And building and iterating the NotesNoteCollection might even trigger the same bad behavior for all I know.