IdeaJam(tm) : Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Domino Designer / : Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Tue, 29 May 2012 14:01:31 +0000

Author: Alexey Katyushyn
Tags: agent
Idea:

It would be nice to be able to call notesAgent.RunOnServer without waiting for the execution of the agent. It would be possible to introduce an optional second parameter IsWaitExecution, the default value is True. Example:

Call notesAgent.RunOnServer( [ noteID$ ], [ IsWaitExecution ] )

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Wed, 30 May 2012 09:18:15 +0000

Author: Kenneth Axi
Comment: Don't see the need for this; the obvious solution would be to run the agent with SendConsoleCommand - then You don't have to wait for the agent to finish before continuing execution of Your agent.

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Wed, 30 May 2012 14:37:29 +0000

Author: Alexey Katyushyn
Comment: This is a workaround. In addition, there is a security restriction on the ability to run SendConsoleCommand.
Much easier to have a second option, as I described!

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Fri, 01 Jun 2012 19:03:45 +0000

Author: Mark Demicoli
Comment: Interesting idea but I think complicated to implement because it introduces synchronisation problems. There would have to be a callback function within the code similar to NotesTimer, again issues arise since the calling code may terminate before the asynchronous call completes. Could you explain why you'd like this feature as there may be an existing way ot achieving same?

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Mon, 04 Jun 2012 20:09:01 +0000

Author: Alexey Katyushyn
Comment: 1. Need to modify the response documents without the author's access to them.
2. Because of the considerable time of document processing, so as not to wait for the end of execution.

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Mon, 04 Jun 2012 21:34:44 +0000

Author: Mark Demicoli
Comment: I'm voting this idea up because I think it might be useful, but I suspect maybe your code or database structure could be more efficient if you're genuinely having application performance issues. How are you updating responses? How long does it typically take?

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Tue, 05 Jun 2012 10:06:15 +0000

Author: Alexey Katyushyn
Comment: Thanks, Mark
In the example of the response document performance problems did not exist. But they may be, if the number of response documents is large.

From what I've come across recently. Developed a custom application for organizing mailings. The user clicks a button to perform list. Newsletter uses an image, the body in html-format, the stream to form a MIME-fields. All this is done on the server and takes time proportional to the number of mailing lists. After pressing the button, after Agent.RunOnServer the user waits for the execution list.

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Tue, 05 Jun 2012 10:17:03 +0000

Author: Mark Demicoli
Comment: OK so for simple updates to Author fields it shouldn't take a huge amount of time even with a large number of documents - on the other hand what you're talking about now is complex processing and mass-mailing.

My suggestion is that you don't process such requests immediately - create a separate database to act as a queue for processing such mailouts, with scheduled agent that runs every 15-30 min. When such a 'publish' occurs a request 'stub' is created in the queue database and processed on schedule. When completed the user that submitted it is notified and stub set to 'completed'. This way you also have an audit of what happened and when, which can be useful.

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Tue, 05 Jun 2012 14:36:32 +0000

Author: Alexey Katyushyn
Comment: Dear Mark,
Initially it was implemented on a schedule agent.
But I thought it could be done better. And tried to use Agent.RunOnServer :)

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Thu, 07 Jun 2012 06:54:15 +0000

Author: Peter Neidhart
Comment: How to you prevent multiple parallel execution of the server agent?
I implemented something similar to this by a small agent that was started by RunOnServer and did nothing else than a tell amgr run...
Based on experience the users will press the button over and over because
they don't get an immediate response.

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Thu, 07 Jun 2012 07:56:32 +0000

Author: Mark Demicoli
Comment: Actually Peter is right Notes is not an assynchronous architecture except for the 'hopelessly fragile' NotesTimer. Voting this down.

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Fri, 29 Jun 2012 00:31:28 +0000

Author: Vlad Sh
Comment: > 9) Peter Neidhart635 (07.06.2012)
> How to you prevent multiple parallel execution of the server agent?
It is perfectly solved by using the (hard-) locking mechanism.

> 10) Mark Demicoli8588 (07.06.2012)
> Actually Peter is right Notes is not an assynchronous architecture except for the 'hopelessly fragile' NotesTimer.
Run multiple background agents and you get all asinhnonnost "problems" described by Peter.

I vote for this idea, as there are many operations where the wait for a response from the server, the user does not need. For example export data in a relational database. The user performed some action, and some data must go immediately. He does not need to wait for the result.

re: Ability to call notesAgent.RunOnServer without waiting for the execution of agent

Tue, 28 Aug 2012 09:31:53 +0000

Author: Simon O'Doherty
Comment: The easiest option for this sort of thing is to create a document which goes to a view that is monitored by an agent. Then have that agent process outstanding requests and move them out of the view.

Easier to audit that way and recover if something went wrong during agent execution.