据我所知，MLCP转换和触发器都可以用于修改摄入的文档。不同之处在于，内容转换在摄取过程中对内存中的文档对象进行操作，而触发器可以在创建文档后触发。
所以在我看来，我没有理由不能同时使用它们。我的用例是，在文档被摄入数据库后，我需要更新文档的一些节点。我使用触发器的原因是，在使用in-mem-update模块的MLCP转换中运行相同的逻辑总是会导致摄取失败，可能是由于文件大小大和我尝试更新的节点数量多。
2018-08-22 23:02:24错误TransformWriter：546-异常：解析HTTP标头时出错：连接尝试失败是因为连接方在一段时间后没有正确响应，或者建立的连接失败是因为所连接的主机未能响应
到目前为止，我还无法组合内容转换和触发器。当我在MLCP接收期间启用转换时，触发器没有被触发。当我禁用转换时，触发器工作正常。
我不能同时使用它们有什么内在的原因吗？还是与我的配置有关？谢谢
编辑：
我想根据@ElijahBernstein Cooper、@MadsHansen和@grtjn的建议提供一些澄清和报告结果的背景(谢谢！)。我使用MarkLogic数据中心框架将PDF文件(有些相当大)作为二进制文件，并将文本提取为XML。除了使用xdmp:pdf-convert而不是xdmp:document-filter之外，我基本上遵循了这个示例：https://github.com/marklogic/marklogic-data-hub/blob/master/examples/load-binaries/plugins/entities/Guides/input/LoadAsXml/content/content.xqy
虽然xdmp:pdf-convert似乎比xdmp:document-filter更好地保留了PDF结构，但它也包括一些我不需要的样式节点(<link>和<style>)和属性(class和style)。在试图去除它们的过程中，我探索了两种不同的方法：
- 第一种方法是使用
in-mem-update模块从上述content.xqy脚本中的内存中文档表示中删除不需要的节点，作为内容转换流程的一部分。问题是这个过程可能很慢，正如@grtjn所指出的，我必须限制并行化以避免超时 - 第二种方法是使用提交后触发函数，在文档被摄入数据库后使用
xdmp:node-delete修改文档。但是，当触发条件设置为document-content("create")时，触发器不会触发。如果我将条件更改为document-content("modify")，它确实会触发，但由于某种原因，我无法使用类似于此SO问题的fn:document($trgr:uri)访问文档(MarkLogic 9 sjs触发器无法访问post-commit()文档数据)
MLCP变换和触发器独立运行。这些转换中没有任何东西可以阻止触发器本身工作。
触发器是由事件触发的。我通常使用创建和修改触发器来覆盖第二次导入相同文件的情况(例如，出于测试目的)。
触发器也有一个作用域。它们被配置为查找目录或集合。确保您的MLCP配置与Trigger作用域匹配，并且您的Transform不会影响URI，使其不再与使用的目录作用域匹配。
然而，仔细查看错误消息，我认为这是由超时引起的。超时既可能发生在服务器端(默认情况下为10分钟)，也可能发生在客户端(可能取决于客户端设置，但可能要小得多)。消息基本上说服务器响应时间太长，所以我认为您正面临客户端超时。
超时可能是由于时间限制过小造成的。您可以尝试增加服务器端(xdmp:set-request-time-limit())和客户端的超时设置(不确定如何在Java中做到这一点)。
不过，更常见的情况是，你只是试图在同一时间做太多。MLCP打开事务，并尝试在该事务中执行多个批处理，也称为transaction_size。每个批次都包含一些batch_size大小的文档。默认情况下，MLCP尝试处理每笔交易10 x 100=1000个文档。
默认情况下，它还使用10个线程运行，因此它通常同时打开10个事务，并尝试运行10个线程来并行处理每个1000个文档。有了简单的插件，这就很好了。由于转换或预提交触发器的处理量更大，这可能会成为瓶颈，尤其是当线程开始争夺内存和cpu等服务器资源时。
像xdmp:pdf-convert这样的函数通常相当慢。对于初学者来说，它依赖于一个外部插件，但也可以想象它必须处理一个200页的PDF。二进制文件可以很大。你需要放慢速度来处理它们。如果使用-transaction_size 1 -batch_size 1 -thread_count 1使您的转换工作，那么您确实面临超时，并且可能已经淹没了服务器。从那里你可以看到一些数字的增加，但二进制大小可能是不可预测的，所以要保守。
异步进行繁重的处理可能也值得一看，例如使用内容处理框架CPF。它是一个用于处理内容的非常健壮的实现，设计用于在服务器重新启动后幸存下来。
啊！