Anyway to increase Max Concurrent Agent limit in Domino Server

Hi,

We are designing a server side agent to take incremental updated data from mailbox for appointment/contacts/calendar and call a webservice to synchronize that data with a CRM system. This agent is predicted to take atleast a minute to execute per user. There are 3000+ users. Plan is to schedule this every hour.

But we have discovered that there is a limit of upto 10 max concurrent agents that can be run at a time which could almost make the server side agent approach not work.

  1. is the approach of running this agent at server incorrect?

  2. is there any way to increase the concurrent agent limit?

  3. is there any other design consideration to work around this problem?

Thanks,

Ayyappa

Subject: Idea…

  • Write a web service on the Domino side and have the CRM system hit that with as many connections as it needs to get the job done. Then Domino should employ as many threads as necessary to service the requests.- Alternatively, write your Domino Agent in Java. A Java Agent can spawn as many worker threads as it likes, as far as I know, allowing you to export as much as you want. Bear in mind I believe the native C code for Document access is not thread safe, so be sure to manage that in your worker threads.

  • Or write a stand-alone Java application to do the same thing, but this will be messier than writing an Agent in Java, because the Agent enjoys integration with the Domino security model.

  • Hope this helps…

Subject: Thanks

Thanks for the suggestions. We are going ahead with server agent that can access multiple mailboxes and do multi threading.

Subject: Concurrent agents

There is no way change the 10 max concurrent agents in the Agent Manager.

Some possible alternatives

  1. How often will the data change in these databases? If not too often you might want to consider ‘new and modified’ trigger. This will stagger executions as needed, and let agent manager load balance.

  2. Consider writing an agent that handles multiple databases, rather than an agent in every mail database. That could be a Java agent with multiple threads to handle each db on a different thread.