Java 在代理未完成时返回200 OK

我在IBMDomino中构建了一个Java代理，它可以通过HTTPPOST接收xml。现在在代理中，当我成功地创建了一个文档，其中包含作为额外数据接收的数据时，我还执行代码，将数据放入第三方软件。最后一部分需要一些时间，比如10-30秒。HTTP POST的发送方正在等待200 OK响应代码，当它等待的时间过长时，将出现超时错误。在我执行将数据放入第三方软件的代码之前，是否有办法将200 OK发送回。例如，这是否可能：

我正在考虑运行另一个代理，将数据放入服务器上的第三方软件中：

     String noteIdtemp = RequestDoc.getNoteID();        
     Agent ag2 = db.getAgent("test");       
     ag2.runOnServer(noteIdtemp); 

但这似乎不起作用，我也犯了一个错误：

09-02-2018 14:52:27   HTTP JVM: NotesException: Could not execute macro:
09-02-2018 14:52:27   HTTP JVM: Unsupported trigger and search in the background or embedded agent
09-02-2018 14:52:27   HTTP JVM:     at lotus.domino.local.Agent.runOnServer(Unknown Source)
09-02-2018 14:52:27   HTTP JVM:     at JavaAgent.NotesMain(Unknown Source)
09-02-2018 14:52:27   HTTP JVM:     at lotus.domino.AgentBase.runNotes(Unknown Source)
09-02-2018 14:52:27   HTTP JVM:     at lotus.domino.NotesThread.run(Unknown Source)

---

欢迎您提供任何建议。

您遇到的错误是，您没有正确设置第二个代理的属性，以便与RunOnServer一起使用。但RunOnServer无法解决您的问题。您的第一个代理将等待第二个代理

不过，我的方法是让第一个代理在某个数据库中创建并保存文档。我将把它称为触发文档，因为这正是我在20年前设计一个使用这个技巧的系统时所说的

您可以将触发器文档写入任何数据库。它不必是应用程序的主数据库。如果你想这样设置的话，它可以，但我假设它是一个独立的数据库，因为那样可能更容易。我叫它AgentQueue db

您将第二个代理放入AgentQueue数据库，并将其设置为运行。您写入AgentQueue的触发器文档需要包含第二个代理将需要的信息，以便为您的第三方过程提供信息，即HTTP POST中提交的数据字段、主应用程序中需要的文档的UNID等

---

您的第一个代理保存触发器文档并退出-向浏览器发送200。第二个代理将很快运行—不一定立即运行，因为它将受到代理管理器中的限制。因为一次只能运行第二个代理的一个副本，所以最好的编写方法是让它在其数据库中查找多个未处理的触发器文档并将其全部处理，而不是只处理一个文档并终止。一旦完成了对触发器文档的处理，它要么将其标记为已完成并保存，要么将其删除。保存它可能很有用，因为如果您愿意，您的第二个代理可以将进度和调试信息写入该文档。

一般来说，如果请求尚未处理，则按照约定，结果代码不是200:OK。这是一个202：接受。安排你的代理，运行，不要太感谢你Richard，还有一个问题：如果这个触发代理需要1分钟来执行，如果我在1分钟内给这个代理打10或100次电话，那么代理还会执行10或100次吗？我上次这么做是很久以前的事了。我记得，在代理运行之前，有一个不太可预测的时间延迟。这就是为什么我建议您编写代理，以便每次运行时，它都能找到自上次运行以来编写的所有触发器文档，并对它们进行处理。但是，如果处理一个触发器文档需要一分钟的时间，那么处理其他触发器文档仍然需要等待。如果你真的很有冒险精神，你可以用Java编写代理并对其进行多线程处理，主线程读取自上次运行以来的所有新触发器文档，并在合理的限制范围内分配额外的线程来处理它们。另一种更简单的同时处理多个数据库的方法是，创建其中10个数据库和10个代理副本，并通过随机选择其中一个来编写触发器文档，编写代码以分散负载。不过，您必须在服务器上配置足够的AMGR线程。我要说的是，如果您谈论的卷接近每分钟100个，甚至可能超过每分钟5或10个，那么您可能根本不应该依赖代理。用C或Java编写并通过OpenNTF OSGi Tasklet服务运行的服务器任务几乎肯定是更好的途径。